Das Wichtigste
- Den Pfad, der Geld einnimmt, von allem anderen isolieren.
- Events für Arbeit nutzen, die nicht vor der Antwort an den Kunden fertig sein muss.
- Jeder Service besitzt seine Daten; geteilt wird über Events, nicht über gemeinsame Tabellen.
- Sobald Anfragen Services überqueren, ist verteiltes Tracing Pflicht.
Wenn Bestellungen, Zahlungen, Speisekarten und Disposition eine Anwendung teilen, kann eine langsame Komponente den Checkout lahmlegen. Wie eventgetriebenes Design Ausfälle isoliert – und was es kostet.
Das Problem mit Spitzen
Die Nachfrage nach Essenslieferungen kommt in steilen Spitzen rund um die Mahlzeiten. In einer einzigen Anwendung konkurrieren Speisekarten-Suche, Empfehlungen, Disposition und Checkout um dieselben Threads, Verbindungen und denselben Speicher. Eine langsame Abfrage in einem Bereich kann Ressourcen aufbrauchen, die der Checkout braucht.
Den Pfad schützen, der Geld einnimmt
Das erste Designprinzip war einfach: Bestellung und Zahlung müssen weiterlaufen, auch wenn alles andere eingeschränkt ist. Deshalb wurden Bestellungen und Zahlungen in eigene Services mit eigenen Datenspeichern getrennt und jede andere Interaktion mit ihnen asynchron gestaltet.
Events für alles, was warten kann
Wenn eine Bestellung eingeht, braucht der Kunde sofort eine Bestätigung. Das Restaurant zu benachrichtigen, einen Fahrer zuzuweisen und Analysen zu aktualisieren, kann einen Moment später geschehen. Ein Event „Bestellung eingegangen“ in Kafka lässt jeden Abnehmer in seinem Tempo arbeiten – und ausfallen, ohne die Bestellung selbst zu beeinträchtigen.
- Bestellservice: nimmt die Bestellung an und veröffentlicht ein Event.
- Restaurantservice: verarbeitet das Event und aktualisiert die Küchenansicht.
- Dispositionsservice: verarbeitet das Event und weist einen Fahrer zu.
- Benachrichtigungsservice: informiert den Kunden, sobald Status-Events eintreffen.
Jeder Service besitzt seine Daten
Bestellungen und Zahlungen brauchen Transaktionen und liegen daher in PostgreSQL. Speisekarten sind Dokumente, deren Form je Restaurant variiert, und liegen in MongoDB. Services lesen nie die Tabellen anderer, sondern halten die benötigten Daten über Events aktuell.
Was es kostet
Eventgetriebene Systeme sind schwerer zu durchschauen als eine einzelne Anwendung. Daten sind letztlich konsistent, Fehler können zwischen Services auftreten, und Debugging heißt, einer Anfrage über mehrere Prozesse zu folgen. Verteiltes Tracing – hier Zipkin – und idempotente Konsumenten sind die Mindestinvestition, die diese Architektur beherrschbar macht.
Für ein kleines internes Werkzeug wäre das Over-Engineering. Für eine Plattform, deren Umsatz davon abhängt, dass der Checkout in Spitzenzeiten läuft, ist es die richtige Abwägung.
Hat es Ihnen gefallen? Den nächsten Beitrag per E-Mail erhalten.