Event-Sourcing Migration: Ein Playbook

Lektion 1: Kein Big-Bang

Ich habe es versucht. Bei einem früheren Projekt (nicht Zalando) wollten wir in einem Wochenende von REST auf Events umstellen. Es hat 3 Wochen gedauert die Folgen zu beheben. Seitdem: stufenweise Migration, immer.

Die Zalando-Migration hat 14 Monate gedauert. Jeder der 180 Services wurde einzeln umgestellt. Das klingt langsam, war aber der einzige Weg der funktioniert.

Lektion 2: Das Dual-Write-Pattern

Der kritische Trick: Events publishen BEVOR die alte Route abgeschaltet wird. Gleichzeitig. 4 Wochen lang. Service A macht REST Call an Service B und publisht gleichzeitig ein Kafka Event an den neuen Event Consumer.

Wenn der Event-Consumer stabil läuft, wird der REST-Call zum no-op. Noch 2 Wochen beobachten. Dann REST entfernen.

Lektion 3: Dead Letter Queues sind Pflicht

Nicht optional. Du wirst Events verlieren. Die Frage ist nur ob du sie wiederfindest.

Bei Zalando hatten wir ca. 0.02% Events die im Dead Letter Queue landeten. Meistens Schema-Mismatches bei Services die noch nicht auf V2 umgestellt waren. Ohne DLQ wären diese Events einfach verschwunden.

Lektion 4: Schema Evolution von Tag 1 planen

Deine Events werden sich ändern. Plane dafür. Wir haben JSON Schema mit Versionsnummern verwendet. Jeder Consumer kennt die Versionen die er versteht.

Lektion 5: Idempotenz ist nicht verhandelbar

Events können doppelt zugestellt werden. Consumer müssen idempotent sein. Keine Ausnahmen.

Fazit

Event-Sourcing-Migrationen sind machbar, aber teuer. Der ROI kommt — bei Zalando war p99 von 2.4s auf 0.65s gerechtfertigt den Aufwand. Bei kleineren Systemen überwiegen die Kosten oft.