Als ein Kunde aus dem Finanzdienstleistungssektor uns bat, sein zentrales Ledger zu migrieren — 14TB Transaktionsdaten, verteilt über drei AWS-Regionen — war die Vorgabe kompromisslos: keine Sekunde für Nutzer sichtbare Ausfallzeit. Die Plattform wickelt rund um die Uhr Zahlungen ab, sodass der übliche Weg über ein Wartungsfenster von Anfang an ausschied.
Das Expand/Contract-Muster
Statt einer einzigen Umschaltung behandelten wir die Migration als Folge rückwärtskompatibler Schritte. Schema und Anwendung entwickeln sich unabhängig voneinander, und zu keinem Zeitpunkt hängt eine laufende Instanz von einer Änderung ab, die nicht bereits ausgeliefert wurde.
- Expand. Neue Spalten, Tabellen und Dual-Write-Pfade hinzufügen. Der alte Code läuft weiter; die neuen Strukturen werden im Hintergrund befüllt.
- Migrate. Historische Zeilen in gedrosselten Batches nachladen, während beide Schemata synchron bleiben.
- Contract. Sobald jeder Leser auf dem neuen Pfad und verifiziert ist, die alten Spalten und den Dual-Write-Shim entfernen.
Jede Phase ist einzeln umkehrbar, wodurch wir das Rollout an jeder Batch-Grenze pausieren konnten, ohne eine Anfrage mitten im Flug zu verlieren.
Drei Regionen im Griff behalten
An der regionsübergreifenden Replikation scheitern die meisten Zero-Downtime-Pläne still und leise. Wir betrieben logische Replikation zwischen Quell- und Zielcluster und machten die finale Promotion von einem kontinuierlichen Checksum-Job abhängig, der Zeilenanzahlen und Hashes pro Partition auf beiden Seiten verglich.
Die Migration fühlte sich nur deshalb sicher an, weil jeder Schritt einen definierten Rollback hatte. Wir überquerten nie eine Brücke, über die wir nicht zurückgehen konnten.
Was wir wieder so machen würden
Zwei Entscheidungen zahlten sich immer wieder aus: den Backfill als idempotenten, fortsetzbaren Job zu schreiben und die Checksum-Abstimmung vor der Umschaltung einem Menschen vorzulegen statt danach. Die gesamte Migration war nach elf Tagen abgeschlossen, und der On-Call-Kanal blieb die ganze Zeit ruhig — was bei einer 14TB-Umstellung über drei Regionen das Ergebnis ist, auf das wir am stolzesten waren.