Saga Pattern

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 den Anfängen der Webentwicklung war das Erstellen einer Softwareanwendung unkompliziert: Sie schrieben Code, packten ihn in ein einzelnes ausführbares oder bereitstellbares Archiv und führten ihn auf einem Server aus. Dieser als Monolithische Architektur bekannte Ansatz hat der Branche jahrzehntelang gute Dienste geleistet. Als sich Anwendungen jedoch zu riesigen Unternehmensplattformen mit Hunderten von Entwicklern und Millionen gleichzeitigen Benutzern entwickelten, stießen Monolithen an ihre Grenzen. Bereitstellungen wurden langsam und riskant, Datenbanken wurden zu Engpässen und Codebasen wurden zu komplex, als dass ein einzelner Entwickler sie verstehen könnte.