Begriff
Event-Driven Architecture (EDA)
Warum wichtig?
Dieser Begriff ist ein Knoten im SengakujiWorks-Wissensnetz. Nutze Level 0 für die erste Einordnung, Level 1 für Praxis, Level 2 für technische Struktur und Level 3 für Grenzen, Fallstricke und Expertenkontext.
Klassisch (Request/Reply): Du bestellst Pizza (Telefon). Du wartest am Hörer, bis der Bäcker sagt: "Okay, ist im Ofen." (Blockierend). Event-Driven (Fire & Forget): Du wirfst einen Zettel in den Briefkasten: "Ich will Pizza." (Event). Du legst dich aufs Sofa. Der Bäcker sieht den Zettel, backt, und wirft einen Zettel bei sich ein: "Pizza fertig." Der Lieferdienst sieht den Zettel "Pizza fertig", holt sie ab und klingelt bei dir. Niemand wartet aktiv. Alles reagiert auf Ereignisse. Das System ist extrem lose gekoppelt.
Merksatz: Ein Architekturstil, bei dem Komponenten durch das Produzieren und Konsumieren von Ereignissen (Events) miteinander kommunizieren, statt sich direkt aufzurufen.
Du brauchst einen Message Broker (Kafka, RabbitMQ). Service A (Bestellung) ruft nicht Service B (Lager) an. Service A schreit einfach in den Raum: "Bestellung eingegangen!" (Publish). Service B hört zu (Subscribe) und reagiert: "Oh, ich muss das Lager checken." Service C (Rechnung) reagiert auch: "Oh, ich muss eine Rechnung schreiben." Vorteil: Du kannst Service D hinzufügen, ohne Service A zu ändern.
1. Event Sourcing
Man speichert nicht den Zustand ("Konto: 100 €"), sondern die Events ("+50", "-20", "+70"). Den Zustand kann man jederzeit neu berechnen (Replay). Perfekt für Audit-Logs (Banken).
2. Choreography vs. Orchestration
- Orchestration (Dirigent): Ein zentraler Prozess sagt: "Erst A, dann B, dann C." (Kontrolle, aber Single Point of Failure).
- Choreography (Tanz): Jeder kennt seine Schritte und reagiert auf die Musik (Events). (Dezentral, aber schwerer zu überblicken). EDA ist meist Choreography.
1. Outbox Pattern vs Two-Phase Commit (2PC)
Das gigantischste Problem von Microservices: Wie ändere ich meine SQL-Datenbank und schreie ein Event in Kafka – ohne Transaktionsfehler? Speichere ich erst in SQL, und Kafka crasht beim Senden, weiß niemand vom Event. Sende ich erst auf Kafka, und SQL crasht ab, melde ich "Bestellt", aber habe in meiner DB nichts stehen. Lösung: Das Transactional Outbox Pattern. Die Business-Tabelle (Order) und eine Event-Tabelle (Outbox) liegen in der gleichen relationalen Datenbank. Man speichert beides in einer einzigen, garantierten SQL-Transaktion. Ein unabhängiger Worker (z.B. Debezium über CDC) liest im Hintergrund nur die DB-Transaktionslogs mit und peitscht diese dann narrensicher und asynchron auf den Kafka Broker.
2. Event Sourcing und CQRS Dualität
In radikalen Event-Driven Systemen mutiert man State nicht (Update/Delete existiert nicht). Die Source of Truth ist das reine Event-Log (Append Only).
Ein Banksystem liest beim Booten 5 Millionen DepositEvent und WithdrawEvent neu ein, um in Memoire den Count "100 Euro" aufzuschichten (Projection).
Um Lesezugriffe (Queries) per HTTP für den User nicht immer durch den Replay-Graph quälen zu müssen, bindet man CQRS. Das Read-Model (MongoDB) ist de-normalisiert auf absolute Lese-Performance und hört rein als Subscriber in die Queue. Das Command/Write Model (EventStore) nimmt gnadenlos Befehle entgegen. Frontend liest links, UI schreibt rechts.
3. Choreography vs Orchestration & Sagas
Wenn ein Event eine Kette startet (1. Order -> 2. Payment -> 3. Shipping), zerbricht verteilte ACID Garantie. Ist Payment erfolgreich, aber Shipping fehlschlägt, muss Payment erstattet werden (Kompensation). In der reinen Choreographie lauscht Payment auf "ShippingFailed" und repariert sich selbst. Dieses Tennis wird nach 10 Services zu einem hochkomplexen Event-Spaghetti. Architekten erzwingen bei tiefen Flows daher das Saga Pattern mit zentraler Orchestrator Node (z. B. AWS Step Functions). Der Orchestrator triggert Services bewusst asynchron, kennt den Status-Graph der Saga, und kommandiert explizit Rückwärts-Kompensationswege (Undo Payment), wenn das Shipping meldet: "Paket ausverkauft".
Quick-Check
Was ist "Eventual Consistency"?
Da alles asynchron ist, dauert es kurz, bis alle Daten überall gleich sind. "Kunde hat gekauft", aber "Lager ist noch nicht leer". Für Millisekunden ist die Welt inkonsistent. Damit muss man leben lernen.Was, wenn ein Event verloren geht?
Darf nicht passieren. Broker wie Kafka garantieren "At-Least-Once Delivery". Deine Services müssen damit klarkommen, dass ein Event vielleicht doppelt kommt (Idempotenz).Warum ist Debuggen schwer?
Weil es keinen "Stack Trace" gibt, der durch alle Services geht. Du musst Logs über mehrere Systeme korrelieren ("Correlation ID"), um zu verstehen, was passiert ist.