Du sollst eine Fähigkeit aus einem großen Monolithen in einen eigenen Service ziehen. Wie machst du das ohne Big-Bang-Release?

Nutz das Strangler-Pattern: setz eine Fassade vor die Fähigkeit, bau den neuen Service dahinter und verschieb den Traffic schrittweise mit einem Feature Flag, während der Monolith der Fallback bleibt. Die Daten trennst du zuletzt, meistens über Dual Writes und Backfill, bis der neue Store führend ist, und du hältst eine Verifikationsphase, in der beide Pfade laufen und Ergebnisse verglichen werden, bevor der alte Code gelöscht wird.

Zuerst würde ich eine Naht schaffen. Selbst innerhalb des Monolithen laufen alle Aufrufer dieser Fähigkeit über ein Interface, was oft ein Refactoring ist, das sich für sich lohnt, weil es zeigt, wie verheddert die Grenze wirklich ist. Dann implementiert der neue Service denselben Vertrag, und die Fassade leitet hinter einem Flag einen kleinen Prozentsatz des Traffics dorthin, beginnend mit Lesezugriffen, wo eine falsche Antwort billig ist. Ich lasse beide eine Weile im Shadow Mode laufen, schicke denselben Request an beide und vergleiche die Antworten, denn das fängt die Edge Cases, die niemand dokumentiert hat. Die Daten sind der harte Teil: ich schreibe doppelt, backfille die Historie, gleiche ab und mache erst dann den neuen Store führend, wobei der Monolith aus dem Service liest statt aus den gemeinsamen Tabellen. Jeder Schritt hat als Rollback das Umlegen eines Flags. Und die Migration ist nicht fertig, bevor der alte Code und seine Tabellen gelöscht sind; ich habe Strangler-Migrationen bei neunzig Prozent hängen sehen, was zwei Systeme zur Pflege über Jahre hinterlässt, und das ist schlimmer als jede der beiden Optionen allein.