Event-Driven Architecture

In herkömmlichen monolithischen Anwendungen ist die Aufrechterhaltung der Datenkonsistenz über mehrere Einheiten hinweg unkompliziert. Relationale Datenbank-Engines bieten ACID-Garantien (Atomizität, Konsistenz, Isolation, Haltbarkeit), die in lokale SQL-Transaktionen eingebettet sind. Wenn eine Auftragserteilung, ein Zahlungsabzug oder eine Lagerbestandsreserve auf halbem Weg fehlschlägt, wird durch den Aufruf von ROLLBACK jede Datenbankänderung sofort rückgängig gemacht. Bei der Migration auf eine moderne Microservices-Architektur verändert sich das Datenmanagement jedoch grundlegend. Um Domänenautonomie und unabhängige Skalierbarkeit sicherzustellen, besitzt jeder Microservice seine private Datenbank. Ein einzelner Geschäftsvorgang – wie die Verarbeitung einer E-Commerce-Kaufabwicklung – erstreckt sich jetzt über mehrere Servicegrenzen und Datenbank-Engines (z. B. PostgreSQL für Bestellungen, DynamoDB für Zahlungen, Redis für Inventar).

In modernen verteilten Softwaresystemen ist die Event-Driven Architecture (EDA) der Grundpfeiler für skalierbare Microservices. Services senden regelmäßig Ereignisse wie OrderCreated oder PaymentProcessed, um Zustandsänderungen sicher zu kommunizieren. Die Herausforderung: Wie stellt man sicher, dass ein Datenbank-Update und das Veröffentlichen des zugehörigen Events entweder beide erfolgreich sind oder beide fehlschlagen? Wenn ein Microservice seine lokale Datenbank aktualisiert und anschließend versucht, ein Event über das Netzwerk an einen Message Broker (wie Apache Kafka oder RabbitMQ) zu senden, können Netzwerkausfälle oder Timeouts zu Dateninkonsistenzen führen.