Vous devez extraire une capacité d'un gros monolithe vers son propre service. Comment feriez-vous sans une mise en production big bang ?

Utilisez le motif strangler : placez une façade devant la capacité, construisez le nouveau service derrière, et déplacez le trafic progressivement avec un feature flag pendant que le monolithe reste le repli. Séparez les données en dernier, en général par double écriture et reprise d'historique jusqu'à ce que le nouveau stockage fasse autorité, et gardez une phase de vérification où les deux chemins tournent et où les résultats sont comparés avant de supprimer l'ancien code.

Je créerais d'abord une couture. Même à l'intérieur du monolithe, tous les appelants de cette capacité passent par une seule interface, ce qui est souvent un refactoring qui vaut le coup en soi parce qu'il révèle à quel point la frontière est emmêlée. Ensuite le nouveau service implémente le même contrat, et la façade route un petit pourcentage du trafic vers lui derrière un flag, en commençant par les appels en lecture seule où une mauvaise réponse coûte peu. Je fais tourner les deux en mode ombre pendant un temps, en envoyant la même requête aux deux et en comparant les réponses, parce que ça attrape les cas limites que personne n'a documentés. Les données sont la partie difficile : je double-écris, je reprends l'historique, je réconcilie, et seulement ensuite je fais du nouveau stockage la source de vérité, le monolithe lisant depuis le service plutôt que depuis les tables partagées. Chaque étape a un retour arrière qui consiste à basculer un flag. Et la migration n'est pas finie tant que l'ancien code et ses tables ne sont pas supprimés ; j'ai vu des migrations strangler caler à quatre-vingt-dix pour cent et laisser deux systèmes à maintenir pendant des années, ce qui est pire que l'une ou l'autre option seule.