Event-Driven-Architektur mit Claude designen: Schema, Idempotenz, Versionierung

1. Warum Event-Driven-Design andere Fehlerklassen erzeugt

Bei synchronen Request-Response-Systemen ist ein Fehler meist sofort sichtbar: Der Aufruf schlägt fehl, und der Client bekommt eine Fehlermeldung. Event-getriebene Systeme entkoppeln Zeitpunkt und Reihenfolge der Verarbeitung, wodurch Fehler oft erst Stunden später auftauchen, etwa wenn ein Consumer ein Event doppelt verarbeitet oder eine veraltete Schema-Version nicht mehr parsen kann. Diese zeitliche Entkopplung macht das Design im Vorfeld deutlich wichtiger als bei klassischen APIs.

Claude eignet sich gut dafür, diese Fehlerklassen systematisch durchzuspielen, bevor der erste Event-Typ überhaupt produziert wird. Statt Claude nach einer generischen Eventarchitektur zu fragen, lohnt es sich, konkrete Szenarien vorzugeben, etwa was passiert, wenn ein Consumer neu gestartet wird und alte Events erneut liest, oder wenn ein Producer ein Event mit einem neuen Pflichtfeld veröffentlicht, das ältere Consumer nicht kennen.

2. Event-Schema-Design: Event Sourcing vs. einfache Domain Events

Eine grundlegende Designentscheidung ist, ob Events lediglich Benachrichtigungen über einen bereits eingetretenen Fachvorgang sind, sogenannte Domain Events wie BestellungVersandt, oder ob der komplette Zustand einer Entität ausschließlich als Sequenz von Events rekonstruiert wird, wie es Event Sourcing vorsieht. Beide Ansätze haben sehr unterschiedliche Konsequenzen für Speicherung, Nachvollziehbarkeit und Komplexität, und Claude kann helfen, diese Konsequenzen konkret für den eigenen Anwendungsfall durchzuspielen, statt sie abstrakt zu bewerten.

Für die meisten Teams ist Event Sourcing eine deutlich größere Investition, weil es Snapshotting, Projektionen und eine sorgfältige Versionsverwaltung des Event-Streams erfordert. Ein hilfreicher Prompt-Ansatz ist, Claude die konkreten fachlichen Anforderungen zu geben, etwa ob eine vollständige Audit-Historie regulatorisch nötig ist, und daraus ableiten zu lassen, ob einfache Domain Events mit einem separaten Audit-Log ausreichen oder Event Sourcing wirklich gerechtfertigt ist.

// Beispiel: Domain Event vs. Event-Sourcing-Event im Vergleich
// Domain Event (Benachrichtigung über einen abgeschlossenen Fachvorgang)
{
  "event_type": "BestellungVersandt",
  "event_id": "evt_8f21a9",
  "occurred_at": "2026-08-08T09:14:22Z",
  "bestellung_id": "ord_5521",
  "tracking_nummer": "DHL-8823741"
}

// Event-Sourcing-Event (Teil der vollständigen Zustandshistorie)
{
  "event_type": "BestellungItemHinzugefügt",
  "aggregate_id": "ord_5521",
  "aggregate_version": 4,
  "event_id": "evt_71c30d",
  "payload": {"sku": "ABC-123", "menge": 2, "preis_cent": 4990}
}

3. Choreography vs. Orchestration mit Claude durchdenken

Bei mehreren Services, die auf ein Event reagieren müssen, stehen zwei grundsätzliche Koordinationsmuster zur Wahl. Choreography lässt jeden Service unabhängig auf Events reagieren und selbst neue Events auslösen, ohne zentrale Steuerung, was lose Kopplung fördert, aber den Gesamtablauf schwer nachvollziehbar macht, sobald mehr als drei oder vier Services beteiligt sind. Orchestration dagegen zentralisiert den Ablauf in einem Prozess-Koordinator, der explizit steuert, wann welcher Service aufgerufen wird, was den Ablauf sichtbarer macht, aber eine neue Form von Kopplung an den Orchestrator einführt.

Claude kann beim Abwägen helfen, indem man ihm die Anzahl beteiligter Services, die erwartete Fehlerbehandlungslogik und die Anforderung an Nachvollziehbarkeit beschreibt. Als Faustregel gilt: Choreography passt gut zu wenigen, stabilen Event-Ketten, während Orchestration bei komplexen Sagas mit vielen Kompensationsschritten, etwa einer mehrstufigen Bestellstornierung, die Fehlerbehandlung deutlich übersichtlicher macht.

# Prompt für Claude Code: Choreography vs. Orchestration abwägen
claude "Wir haben 5 Services, die bei einer Bestellstornierung reagieren
müssen (order, payment, inventory, shipping, notification). Die
Stornierung braucht Kompensationslogik, falls ein Schritt fehlschlägt.
Vergleiche Choreography und Orchestration für diesen konkreten Fall:
- Wie sichtbar bleibt der Gesamtablauf bei Fehlern?
- Wo entsteht neue Kopplung?
- Welches Muster passt besser zu Sagas mit Kompensationsschritten?
Gib eine begründete Empfehlung, keine reine Auflistung von Vor-/Nachteilen.

4. Idempotenz: Der häufigste Fallstrick im Review

At-least-once-Delivery ist in den meisten Messaging-Systemen die Regel, nicht die Ausnahme, das heißt jeder Consumer muss damit rechnen, ein Event mehrmals zu empfangen, etwa nach einem Netzwerkfehler oder einem Consumer-Neustart vor der Bestätigung. Ohne Idempotenz führt ein doppelt verarbeitetes ZahlungEingegangen-Event im schlimmsten Fall zu einer doppelten Gutschrift. Claude kann Consumer-Code gezielt darauf prüfen, ob eine Idempotenz-Absicherung fehlt, etwa über einen eindeutigen Event-Schlüssel mit Deduplizierung vor der eigentlichen Verarbeitung.

Ein typisches Review-Muster ist, Claude den Consumer-Code zusammen mit der Frage vorzulegen, was bei zweimaligem Empfang desselben Events passiert. Häufig zeigt sich dabei, dass zwar die fachliche Logik korrekt ist, aber keine Prüfung auf bereits verarbeitete Event-IDs existiert, ein Muster, das in Code-Reviews ohne gezielten Blick auf Idempotenz leicht übersehen wird, weil der Code im Normalfall, also bei einmaliger Zustellung, fehlerfrei funktioniert.

5. Event-Versionierung: Schema-Evolution ohne Consumer zu brechen

Events werden oft über Jahre von unterschiedlichen Consumern gelesen, die zu unterschiedlichen Zeitpunkten deployt wurden, weshalb Schema-Änderungen abwärtskompatibel bleiben müssen. Ein neues optionales Feld ist meist unkritisch, das Umbenennen oder Entfernen eines bestehenden Feldes dagegen bricht ältere Consumer sofort. Claude kann beim Review eines geplanten Schema-Changes gezielt prüfen, ob die Änderung additiv bleibt oder eine Breaking Change darstellt, die eine neue Event-Version mit paralleler Auslieferung erfordert.

In der Praxis bewährt sich, Claude sowohl das alte als auch das neue Schema vorzulegen und explizit nach Breaking Changes fragen zu lassen, statt sich auf eine informelle Einschätzung im Team zu verlassen. Zusätzlich lohnt sich eine feste Konvention, etwa ein schema_version-Feld in jedem Event, damit Consumer beim Parsen erkennen können, welche Version sie gerade verarbeiten und wie sie mit unbekannten neuen Feldern umgehen sollen.

# Prompt für Claude Code: Breaking Change im Event-Schema erkennen
claude "Vergleiche das alte Event-Schema (schema_v1.json) mit dem neuen
Entwurf (schema_v2_draft.json) für BestellungErstellt. Prüfe:
- Wird ein bestehendes Feld umbenannt, entfernt oder der Typ geändert?
- Werden neue Pflichtfelder ohne Default eingeführt?
- Könnte ein Consumer, der nur v1 kennt, das neue Event fehlinterpretieren?
Markiere jede Aenderung explizit als 'additiv' oder 'breaking'.

6. Persistenz-Ebene: Event-Store, Broker und Retention

Ein oft übersehener Designaspekt ist, wie lange Events überhaupt verfügbar bleiben und wer für ihre Persistenz verantwortlich ist. Ein reiner Message Broker mit kurzer Retention eignet sich für Fire-and-Forget-Benachrichtigungen, aber nicht als verlässliche Quelle der Wahrheit, wenn ein neuer Consumer später historische Events nachlesen muss. Ein dedizierter Event-Store mit langer oder unbegrenzter Retention ist dagegen notwendig, wenn Event Sourcing oder ein Audit-Trail Teil der Architektur ist.

Claude kann bei dieser Entscheidung helfen, indem man ihm die tatsächlichen Anforderungen an Nachvollziehbarkeit, Replay-Fähigkeit für neue Consumer und regulatorische Aufbewahrungsfristen beschreibt. Wichtig ist dabei, Claude nicht nach der technisch elegantesten Lösung zu fragen, sondern nach der Lösung, die zu den konkreten Betriebskosten und der vorhandenen Infrastruktur des Teams passt, da ein voller Event-Store deutlich mehr operativen Aufwand bedeutet als ein einfacher Broker.

7. Dead Letter Queues: Was mit nicht verarbeitbaren Events passiert

Nicht jedes Event lässt sich erfolgreich verarbeiten, etwa wenn die Payload fehlerhaft ist, eine referenzierte Entität bereits gelöscht wurde oder ein Consumer wiederholt mit einem transienten Fehler abbricht. Ohne eine Dead Letter Queue verschwindet ein solches Event entweder stillschweigend oder blockiert die gesamte Warteschlange, weil das System immer wieder denselben fehlerhaften Eintrag erneut zustellt, bevor es zum nächsten Event übergehen kann. Claude kann beim Review von Consumer-Code gezielt danach fragen, wohin ein Event nach einer festgelegten Anzahl fehlgeschlagener Verarbeitungsversuche verschoben wird.

Ebenso wichtig wie die reine Existenz einer Dead Letter Queue ist ein definierter Prozess für den Umgang mit ihr: Wer wird benachrichtigt, wenn dort Events landen, wie werden sie nach einer Fehlerbehebung erneut eingespielt, und wie lange bleiben sie dort aufbewahrt. Claude kann helfen, diesen operativen Prozess zusammen mit der technischen Implementierung zu skizzieren, damit eine Dead Letter Queue nicht zu einem stillen Datenfriedhof wird, den niemand mehr regelmäßig prüft.

8. Ein wiederverwendbarer Review-Prompt für Event-Designs

Ähnlich wie bei Microservices-Grenzen lohnt sich eine feste Checkliste, die bei jedem neuen Event-Typ als Prompt-Grundlage dient: Ist das Event idempotent verarbeitbar, existiert ein eindeutiger Event-Schlüssel, ist die Reihenfolge der Verarbeitung fachlich relevant oder nicht, ist das Schema additiv erweiterbar, und gibt es eine klare Owner-Zuordnung für das Event-Schema. Diese Kriterien lassen sich als festes Prompt-Template speichern und bei jedem neuen Event konsistent anwenden.

Ein zusätzlicher Punkt, der in der Praxis oft fehlt, ist die explizite Frage nach der Reihenfolgegarantie: Viele Messaging-Systeme garantieren Reihenfolge nur innerhalb einer Partition oder eines Topics, nicht global. Claude kann beim Review helfen zu erkennen, ob die Fachlogik fälschlich eine globale Reihenfolge annimmt, obwohl das zugrunde liegende System diese Garantie gar nicht bietet, ein Fehler, der sich oft erst unter Last zeigt.

9. Grenzen: Claude kennt nicht die reale Nachrichtenrate

So hilfreich Claude beim Durchdenken von Schema und Kommunikationsmuster ist, es kennt weder die tatsächliche Nachrichtenrate im Produktivbetrieb noch die reale Latenzverteilung zwischen Producer und Consumer noch das konkrete Verhalten des gewählten Message Brokers unter Last. Design-Entscheidungen, die auf dem Papier gut aussehen, etwa Choreography mit sechs beteiligten Services, können bei tatsächlich hoher Nachrichtenrate zu Problemen führen, die sich erst im Monitoring zeigen.

Deshalb sollte jeder mit Claude erarbeitete Entwurf durch Lasttests und echtes Monitoring in einer Staging-Umgebung verifiziert werden, bevor er produktiv geht. Claude liefert die konzeptionelle Vorarbeit und macht Fallstricke wie fehlende Idempotenz sichtbar, die endgültige Verifikation gegen reale Systemcharakteristika bleibt aber Aufgabe des Teams mit echten Metriken aus dem Betrieb.

10. Zusammenfassung

11. FAQ: Event-Driven-Architektur mit Claude: Die wichtigsten Fragen