6 Abgrenzung zu REST und synchronen Systemen

Um Event-Driven Architecture wirklich zu verstehen, müssen wir sie im Kontext etablierter Kommunikationsparadigmen betrachten. Die meisten Entwickler sind mit synchronen REST-APIs vertraut, da diese seit Jahren den Standard für Service-Kommunikation darstellen. Event-Driven Architecture bricht mit diesem vertrauten Muster und führt ein fundamental anderes Denkmodell ein.

Synchrone Systeme folgen einem imperativen Ansatz – wir sagen dem System explizit, was es tun soll. Event-getriebene Systeme hingegen folgen einem deklarativen Ansatz – wir beschreiben, was passiert ist, und lassen das System entsprechend reagieren.

6.1 Request-Response vs. Event-Driven Communication

Die fundamentalen Unterschiede zwischen beiden Ansätzen werden in der direkten Gegenüberstellung deutlich:

Aspekt Request-Response (REST) Event-Driven Communication
Kommunikationsmuster Direkter Aufruf zwischen Services Events über Message Broker
Kopplung Eng gekoppelt - Services kennen sich Lose gekoppelt - Services kennen nur Events
Zeitverhalten Synchron - Warten auf Antwort Asynchron - Fire-and-Forget
Fehlerbehandlung Sofortige Fehlerrückmeldung Retry-Mechanismen, Dead Letter Queues
Skalierung Vertikal, gesamtes System Horizontal, pro Service
Konsistenz Starke Konsistenz Eventual Consistency
Debugging Linear verfolgbar Verteiltes Tracing erforderlich

6.1.1 E-Commerce-Beispiel: Bestellprozess

REST-Ansatz:

  1. Frontend → POST /orders (wartet)
  2. Order-Service → POST /payment (wartet)
  3. Order-Service → POST /inventory (wartet)
  4. Order-Service → POST /shipping (wartet)
  5. Antwort an Frontend (alle Schritte abgeschlossen)

Event-Driven-Ansatz:

  1. Frontend → POST /orders → sofortige Bestätigung
  2. Order-Service → publiziert “BestellungAufgegeben”-Event
  3. Payment-, Inventory-, Shipping-Services reagieren parallel
  4. Frontend erhält Updates über separate Kanäle

6.2 Vor- und Nachteile beider Ansätze

6.2.1 REST/Synchrone Systeme

Vorteile ✅ Nachteile ❌
Einfaches Debugging - Linearer Request-Flow Kaskadierender Ausfall - Ein Service-Ausfall blockiert alles
Sofortiges Feedback - Klare Success/Error-Responses Enge Kopplung - Services müssen sich kennen
Etablierte Tools - Mature HTTP-Ecosystem Schlechte Skalierung - Schwächstes Glied limitiert System
Vorhersagbar - Deterministisches Verhalten Blockierende Operationen - Lange Antwortzeiten
Einfaches Caching - HTTP-Caching-Mechanismen Schwere Evolution - Breaking Changes propagieren

6.2.2 Event-Driven Systeme

Vorteile ✅ Nachteile ❌
Lose Kopplung - Services entwickeln unabhängig Komplexes Debugging - Verteilter Event-Flow
Horizontale Skalierung - Granulare Service-Skalierung Eventual Consistency - Temporäre Inkonsistenzen
Ausfalltoleranz - Graceful Degradation Operational Complexity - Message Broker Management
Parallelverarbeitung - Asynchrone Background-Jobs Neue Skills erforderlich - Async Programming
Natürliche Audit-Trails - Events als Geschäftslog Duplicate Events - Idempotenz erforderlich

6.2.3 Wann welcher Ansatz?

Szenario Empfohlener Ansatz Begründung
User-Interface-Calls REST/Synchron Sofortiges Feedback erforderlich
CRUD-Operationen REST/Synchron Einfache Lese-/Schreibvorgänge
Backend-Integration Event-Driven Lose Kopplung zwischen Services
Batch-Processing Event-Driven Parallele Verarbeitung großer Datenmengen
Real-time Analytics Event-Driven Kontinuierliche Stream-Verarbeitung
Critical Transactions REST/Synchron ACID-Garantien erforderlich

6.3 Hybride Architekturen

Moderne Systeme sind selten rein synchron oder rein event-getrieben. Hybride Ansätze kombinieren die Stärken beider Welten und minimieren ihre Schwächen.

6.3.1 Bewährte Hybrid-Patterns

Pattern Beschreibung E-Commerce-Beispiel
Sync for Commands, Async for Events User-Aktionen synchron, Backend-Processing asynchron POST /orders → sofortige Bestätigung + async Processing
Query-Command-Separation Lesevorgänge synchron, Schreibvorgänge event-driven GET /products (sync) vs. “BestellungAufgegeben” (async)
Event-Carried State Transfer Events enthalten alle nötigen Daten “KundeRegistriert” mit Profildaten → keine API-Calls nötig
Synchrone Fallbacks Event-System + REST-Backup für kritische Ops Payment via Events, bei Ausfall REST-API
API Gateway Translation Gateway wandelt REST ↔︎ Events um Mobile App → REST → Gateway → Events

6.3.2 Evolution zur Hybrid-Architektur

Typischer Migrationspfad von monolithischen zu hybriden Systemen:

Phase 1: Monolith mit REST-APIs
↓
Phase 2: Microservices mit REST-Integration  
↓
Phase 3: Hybrid - REST für UI, Events für Backend
↓
Phase 4: Event-First mit synchronen Fallbacks

6.3.3 Architektur-Entscheidungsregeln

Verwende REST/Synchron für:

Verwende Events/Asynchron für:

6.3.4 Konsistenz in hybriden Systemen

Hybride Architekturen erfordern klare Regeln, um Inkonsistenzen zu vermeiden:

Herausforderung Lösungsansatz
Event-REST-Sync Events für State Changes, REST für Queries
Duplicate Operations Idempotenz-Keys bei REST + Event-Overlap
Consistency Boundaries Klare Abgrenzung sync/async Domains
Error Handling Unterschiedliche Retry-Strategies je Pattern

Der Schlüssel zum Erfolg hybrider Architekturen liegt in klaren Architekturentscheidungen und konsistenter Anwendung. Teams müssen verstehen, wann sie welches Pattern einsetzen, und diese Entscheidungen dokumentieren.

Die meisten erfolgreichen modernen Systeme nutzen REST für User-facing APIs und Events für Backend-Integration – eine Kombination, die Entwicklerproduktivität mit Systemskalierbarkeit optimal verbindet.