Event-Driven Architecture (EDA)

Klassisch: Service A ruft Service B per HTTP. B antwortet. Synchron, fest gekoppelt.

Event-Driven: A publiziert ein Event. Wer interessiert ist, abonniert. Asynchron, lose gekoppelt.

Beispiel: Bestellung aufgegeben

OrderService.publish('OrderPlaced', { orderId: 42, userId: 7, amount: 99.50 })

→ InventoryService    : reserviert Bestand
→ PaymentService      : versucht Zahlung
→ EmailService        : sendet Bestellbestätigung
→ AnalyticsService    : trackt Conversion
→ LoyaltyService      : rechnet Punkte gut

Order-Service muss NICHT wissen, wer alles reagiert. Neue Subscriber? Einfach hinzufügen, kein Code-Change beim Publisher.

Vorteile

• Lose Kopplung: Services kennen einander nicht direkt
• Skalierbarkeit: Subscriber pro Event-Typ skalieren
• Resilienz: Subscriber down → Events queued, später verarbeitet
• Auditierbarkeit: Event-Log = History allen Geschehens

Nachteile

• Eventual Consistency: nicht alle Subscriber haben sofort denselben Stand
• Debugging: "wer hat was wann gemacht?" — schwer ohne Tracing
• Event-Schema-Evolution: alte Subscriber müssen neue Felder ignorieren können
• Duplikate: at-least-once-Delivery → Subscriber müssen idempotent sein