Event-Driven ist kein Selbstzweck. Es loest spezifische Probleme, und schafft neue.
Wann Event-Driven sinnvoll ist
Wenn Systeme lose gekoppelt werden sollen, etwa wenn der Publisher einer Bestellung nicht wissen muss, welche weiteren Services darauf reagieren. Wenn Lastspitzen abgefedert werden sollen, weil eine Queue zwischen zwei Systemen puffert und das nachgelagerte System in seinem eigenen Tempo verarbeitet. Und wenn Ausfalltoleranz gefragt ist, weil Nachrichten in der Queue liegen bleiben, bis das empfangende System wieder verfuegbar ist.
Kafka gegen RabbitMQ
Kafka bietet hohen Durchsatz und eine persistente, Log-basierte Architektur, bei der Nachrichten lange verfuegbar bleiben und sich fuer Replay eignen, gut fuer Event Streaming und Audit Logs, allerdings mit hoeherem Betriebsaufwand. RabbitMQ ist der klassische Message Broker, einfacher zu betreiben, gut fuer Task Queues und Work Distribution, Nachrichten werden nach Verarbeitung geloescht. Fuer die meisten mittelgrossen Projekte reicht RabbitMQ, Kafka lohnt sich erst bei wirklich hohen Volumina oder wenn Event-Replay gebraucht wird.
Das Outbox-Pattern
Ein Datenbank-Update und eine Queue-Nachricht in einer atomaren Transaktion abzubilden ist schwierig, geht die Nachricht nach dem Update verloren, entsteht ein inkonsistenter Zustand. Die Loesung: eine Outbox-Tabelle in derselben Transaktion wie das Update, ein separater Prozess liest die Outbox und schreibt in die Queue, atomar garantiert.
Checkliste: Event-Driven-Anwendungsfall klar identifiziert, passende Broker-Technologie gewaehlt, Outbox Pattern fuer kritische Events implementiert, idempotente Consumer-Implementierung, Dead Letter Queue vorhanden, Monitoring fuer Queue-Tiefe und Consumer-Lag.
Ein Beispiel aus der Praxis
Ein System verarbeitete Bestellereignisse ueber eine Queue, ohne dass die Verarbeitung idempotent war. Bei einem kurzzeitigen Netzwerkproblem wurden einzelne Nachrichten doppelt zugestellt, was zu doppelt versendeten Bestaetigungs-E-Mails an Kunden fuehrte, ein kleiner, aber sichtbarer und peinlicher Fehler. Nach der Einfuehrung einer einfachen Pruefung auf bereits verarbeitete Event-IDs vor jeder Aktion verarbeitete das System doppelt zugestellte Nachrichten korrekt, ohne dass Kunden davon je wieder etwas bemerkten.
Event-Driven-Architektur fuer euer Projekt? markom.digital entwirft und implementiert event-driven Integrationen, von der Architektur bis zur Produktionsumgebung.
