Event-getriebene Microservices versprechen Entkopplung, Skalierbarkeit und bessere Ausfallsicherheit. Ein Service veröffentlicht ein Ereignis und muss nicht warten, bis alle nachgelagerten Verbraucher fertig sind. Das kann Kaskadenausfälle reduzieren und unabhängige Verarbeitung ermöglichen. Der Preis ist ein anderes Betriebsmodell: Zustände werden zeitversetzt konsistent, Nachrichten können mehrfach eintreffen und Fehler verteilen sich über Producer, Broker, Consumer und Schemas.
Der n8n-Leitfaden empfiehlt deshalb keinen vollständigen Wechsel von APIs zu Events. Moderne Systeme kombinieren häufig synchrone Aufrufe für Aktionen mit unmittelbarem Nutzerfeedback und asynchrone Events für nachgelagerte Arbeit. Für Unternehmen ist diese Hybridentscheidung zentral. Checkout-Autorisierung, Login oder eine verbindliche Preisabfrage brauchen oft sofortige Antwort. Analyse, Benachrichtigung oder spätere Dokumenterzeugung können entkoppelt ablaufen.
Was Event-getrieben konkret bedeutet
Microservices definieren fachliche Servicegrenzen; Event-Driven Architecture definiert den Kommunikationsstil. Ein Producer veröffentlicht ein Ereignis, ein Broker hält oder verteilt es und ein oder mehrere Consumer reagieren mit eigener Geschäftslogik. Der Producer kennt nicht zwingend alle Empfänger. Dadurch lassen sich neue Verbraucher ergänzen, ohne den ursprünglichen Service direkt zu verändern. Gleichzeitig wird die zeitliche Reihenfolge der Gesamtwirkung schwerer sichtbar.
Microservices define service boundaries, while event-driven architecture defines the communication style.
n8n
n8n unterstützt laut eigener Darstellung RabbitMQ, Apache Kafka und AWS SQS und kann Events, APIs sowie nachgelagerte Workflows orchestrieren. Das macht n8n zu einer möglichen Integrationsschicht, ersetzt aber weder Brokerbetrieb noch fachliches Zustandsdesign. Die Wahl zwischen Kafka, RabbitMQ oder SQS hängt von Durchsatz, Reihenfolge, Routing, Betriebskompetenz und Cloudstrategie ab. Der Leitfaden bestätigt keine pauschale Überlegenheit eines Brokers.
Synchron oder asynchron entscheiden
- Synchron: Nutzer oder aufrufender Service braucht sofort eine verbindliche Antwort.
- Asynchron: Nachgelagerte Arbeit darf später erfolgen und soll den Hauptpfad nicht blockieren.
- Synchron: starke Konsistenz ist vor der nächsten Aktion zwingend erforderlich.
- Asynchron: mehrere unabhängige Consumer sollen auf dasselbe Ereignis reagieren.
- Hybrid: Kernentscheidung synchron bestätigen, Folgeprozesse über ein verlässliches Event auslösen.
Ein Beispiel ist eine Bestellung. Zahlungsauthorisierung und Bestellbestätigung können einen synchronen Pfad benötigen. Nach erfolgreicher Entscheidung werden Events für Rechnung, Analytics, Lageraktualisierung und Benachrichtigung veröffentlicht. Wichtig ist, dass das Event erst dann zuverlässig entsteht, wenn der fachliche Zustand festgeschrieben wurde. Andernfalls kann die Bestellung gespeichert sein, während das Ereignis verloren geht. Muster wie eine transaktionale Outbox adressieren diese Lücke.
Vier Produktionsrisiken beherrschen
Erstens müssen Consumer doppelte Zustellungen idempotent verarbeiten. Broker und Netzwerke garantieren häufig mindestens eine Zustellung, nicht exakt eine Geschäftswirkung. Ein stabiler Event-Key und atomare Verarbeitung verhindern Mehrfachbuchungen oder doppelte Nachrichten. Zweitens verlangt Eventual Consistency einen sichtbaren Zwischenzustand. Nutzer und Support müssen erkennen können, ob ein Folgeprozess aussteht, fehlgeschlagen oder abgeschlossen ist.
Drittens werden Event-Schemata wie APIs versioniert. Neue Felder sollten kompatibel ergänzt, entfernte oder umgedeutete Felder kontrolliert migriert werden. Producer dürfen nicht annehmen, dass alle Consumer gleichzeitig aktualisiert werden. Viertens braucht Debugging eine durchgängige Korrelation. Trace-ID, Event-ID, fachlicher Schlüssel, Schema-Version und Zeitstempel müssen über Broker und Workflows hinweg auffindbar sein, ohne sensible Payloads unnötig zu duplizieren.
- Event mit fachlichem Namen, Owner, Schema, Version und Lebensdauer definieren.
- Publikation und fachliche Zustandsänderung gegen Verlust oder Doppelwirkung absichern.
- Consumer auf Duplikate, Reihenfolgefehler, Timeouts und Wiederanlauf testen.
- Dead-Letter-, Retry-, Replay- und manuelle Klärungswege mit Grenzen festlegen.
- Ende-zu-Ende-Latenz, Backlog, Fehlerzustände und fachliche Konsistenz überwachen.
Schema-Versionierung und Replay
Ein Event ist ein Vertrag. Consumer können auch Monate später noch eine ältere Version sehen, wenn Backlogs oder Replays genutzt werden. Deshalb sollten Schemas in einem Register oder einer klaren Repository-Struktur versioniert und automatisiert auf Kompatibilität geprüft werden. Semantische Änderungen brauchen oft einen neuen Eventtyp oder eine explizite Version. Nur den Feldnamen beizubehalten, während die Bedeutung wechselt, ist besonders gefährlich.
Replay ist mächtig, weil neue Consumer historische Ereignisse verarbeiten oder fehlerhafte Projektionen neu aufbauen können. Es kann aber erneut E-Mails, Buchungen oder externe Aktionen auslösen. Vor einem Replay werden Consumer in einen sicheren Modus versetzt, Zeitbereich und Eventmenge begrenzt und irreversible Wirkungen blockiert. Datenaufbewahrung, Datenschutz und Löschanforderungen müssen auch für persistierte Event-Logs gelten.
Observability für verteilte Wirkung
Ein erfolgreich veröffentlichter Event bedeutet nicht, dass der Geschäftsprozess abgeschlossen ist. Monitoring muss Producer, Broker, Consumer und fachliches Ergebnis verbinden. Technische Kennzahlen wie Consumer Lag, Retryrate und Dead Letters werden mit Business-Zuständen wie ausstehenden Rechnungen oder fehlenden Benachrichtigungen kombiniert. Sonst kann die Plattform grün erscheinen, während Kundenprozesse unvollständig bleiben.
Für Incidents braucht es klare Zuständigkeit. Der Event-Owner verantwortet Semantik und Schema, der Plattform-Owner den Broker, der Consumer-Owner die jeweilige Wirkung. Alarmierung sollte zum Team führen, das handeln kann. Eine Runbook-Kette erklärt, wie Nachrichten pausiert, zurückgehalten, erneut verarbeitet oder manuell korrigiert werden. Unkontrolliertes Löschen eines Backlogs beseitigt Symptome und kann Geschäftsdaten dauerhaft inkonsistent machen.
Einführung ohne Big Bang
Ein guter Einstieg ist ein nachgelagerter Prozess mit tolerierbarer Verzögerung und klarer Baseline. Das Team betreibt zunächst einen Consumer, testet Duplikate, Ausfälle und Schemaänderungen und misst Ende-zu-Ende-Wirkung. Erst danach kommen weitere Verbraucher hinzu. Synchrone Kernpfade werden nicht nur aus Architekturmode ersetzt. Der Nutzen muss sich durch geringere Kopplung, bessere Skalierung oder robustere Fehlerisolation belegen lassen.
Fazit
Event-getriebene Microservices sind kein Ersatz für synchrone APIs, sondern eine ergänzende Kommunikationsform. Sie eignen sich für entkoppelte Folgeprozesse und mehrere unabhängige Consumer, verlangen aber explizite Regeln für Eventual Consistency, Idempotenz, Schemaevolution, Replay und Observability. Unternehmen sollten mit einem begrenzten Hybridfall starten und die geschäftliche Wirkung Ende zu Ende messen. Erst beherrschte Produktion macht aus asynchroner Architektur echte Resilienz.