Comment extraire un service d'un monolithe en sécurité

Le premier service extrait doit prouver que le monolithe peut céder une responsabilité sans perdre le contrôle. Choisissez-le selon la propriété des données et le risque de déploiement, pas selon la facilité avec laquelle on trace une jolie boîte autour d'un module. Un package bien rangé qui partage des tables, reçoit des appels synchrones et participe à une grande transaction reste une partie du monolithe sur tous les plans importants.

J'ai vu des équipes extraire le code qui semblait le plus isolé, fêter la propreté du nouveau dépôt, puis découvrir que chaque mise en production exigeait une modification coordonnée de la base et un appel nocturne à trois responsables. Le service existait comme processus, mais pas comme unité opérationnelle. Le premier véritable incident de production l'a renvoyé tout droit dans le monolithe.

Une bonne première extraction possède une surface d'écriture étroite, des données qui peuvent avoir un propriétaire clair, des appelants capables de supporter une frontière réseau et un chemin de mise en production réversible sans réparation manuelle des données. Elle peut sembler ennuyeuse sur le schéma d'architecture. C'est une qualité quand l'équipe apprend encore comment son système se comporte réellement.

Commencez par la propriété des données, pas par un nom métier

Le meilleur premier service possède un ensemble cohérent de faits et peut refuser une écriture sans consulter la moitié du monolithe. Ce critère va plus loin que la présence de classes nommées Billing, Customer ou Inventory. Un nom métier recouvre souvent des processus, rapports, autorisations et tables historiques que différents chemins de code modifient pour des raisons distinctes.

Demandez quelle composante peut devenir l'unique autorité sur un petit ensemble d'enregistrements. Être propriétaire signifie valider les changements, les valider en base, attribuer les identifiants et publier le résultat. D'autres composants peuvent mettre ces faits en cache ou les copier, mais ils ne modifient plus les lignes de référence. Si le monolithe et le nouveau service restent tous deux des auteurs légitimes, vous avez créé une course distribuée au lieu d'une frontière.

Suivez les écritures avant les lectures. Les lectures sont généralement plus faciles à dupliquer, à mettre en cache ou à servir par une vue de compatibilité. Les écritures révèlent les règles qui maintiennent la validité des données. Cherchez dans le code applicatif, les procédures stockées, les tâches planifiées, les déclencheurs de base, les scripts d'import, les outils d'assistance et les commandes directes des opérateurs. Les anciens systèmes cachent souvent des écritures décisives hors des endroits visibles dans le dépôt principal.

Un bon candidat peut posséder les demandes de génération de documents, les préférences de notification, les instantanés de taux de change ou les tâches d'export terminées. Ces exemples ont une transition d'état délimitée et acceptent souvent un traitement asynchrone. Un mauvais candidat s'appelle souvent client, commande, compte ou droit lorsque ces enregistrements participent à chaque transaction importante. Ces domaines pourront devenir des services plus tard. Les choisir en premier force la migration à enseigner la leçon la plus difficile au prix le plus élevé.

Ne confondez pas un groupe de tables avec un domaine. Si une table reçoit douze clés étrangères, déclenche deux mises à jour d'autres agrégats et subit une correction nocturne, son déplacement ne crée aucune indépendance. Il déplace le centre d'un réseau de dépendances. La documentation PostgreSQL décrit les clés étrangères comme des dépendances entre les lignes qui référencent et celles qui sont référencées. Cette garantie reste locale à la transaction de base de données. Lorsque les tables passent derrière des services distincts, l'application doit la remplacer volontairement ou accepter une cohérence plus faible.

Mesurez le couplage avec des preuves d'exécution

Les graphes de dépendances statiques sont un point de départ, mais les données de production révèlent si un candidat survivra à une frontière de processus. Instrumentez le monolithe assez longtemps pour observer les appelants, la forme des requêtes, la fréquence d'écriture, la durée des transactions, la taille des charges, la sensibilité à la latence, les nouvelles tentatives et les pics de trafic. L'unité utile n'est pas un fichier source. C'est une requête ou une tâche qui traverse la future frontière.

Tenez un registre avec une ligne par service envisagé. Notez les tables lues et écrites, chaque appelant, la présence de chaque appel dans une requête utilisateur, la possibilité d'attendre après un échec et les invariants qui dépendent aujourd'hui d'une même transaction. Ajoutez le responsable du déploiement et l'action de retour. Si l'une de ces cases indique «à décider», le candidat n'est pas prêt.

La recherche dans le dépôt manque le SQL dynamique, la réflexion, les requêtes générées et le code déployé ailleurs. Les journaux de requêtes et les traces de base de données capturent ces chemins. Échantillonnez assez longtemps pour inclure les tâches planifiées comme le règlement, la facturation, le rapprochement, l'archivage et la clôture mensuelle. Le point de terminaison calme du mardi peut devenir le centre du système le dernier jour ouvré du mois.

Comptez les opérations transfrontalières plutôt que les appels de méthodes. Une méthode de dépôt bavarde peut lancer vingt requêtes, mais migrer proprement avec ses données. Un simple getter peut appartenir à une transaction qui verrouille des lignes dans quatre domaines. La documentation de PostgreSQL sur les verrous explicites précise que SELECT FOR UPDATE bloque les mises à jour et demandes de verrou concurrentes jusqu'à la fin de la transaction. Remplacer cette attente locale par un appel distant modifie le calendrier, les modes de panne et les interblocages, même si les champs renvoyés restent identiques.

Traitez un trafic inconnu comme un risque, pas comme un zéro. Quand les journaux n'identifient pas l'auteur d'une mise à jour, ajoutez de l'observation avant l'extraction. Un proxy, un déclencheur d'audit temporaire ou une étiquette de trace dans la couche d'accès aux données peut révéler cet auteur. Deviner ne gagne du temps que jusqu'au moment où l'auteur inconnu écrase l'état du nouveau service.

Les preuves doivent répondre à quatre questions gênantes: le service peut-il être indisponible sans bloquer la transaction principale? Un appelant peut-il réessayer sans dupliquer le travail? Un opérateur peut-il dire quelle copie d'un enregistrement fait foi? L'équipe peut-elle désactiver la route tout en gardant les deux stockages cohérents en interne? Un premier service n'a pas besoin de quatre réponses parfaites, mais chaque réponse faible exige un contrôle testé.

Un schéma propre peut masquer une très mauvaise découpe

Écartez les candidats dont l'attrait repose surtout sur l'ordre organisationnel. Les équipes choisissent souvent un module parce qu'une seule équipe le possède déjà, que son espace de noms est propre ou qu'un schéma fournisseur le qualifie de contexte délimité. Aucun de ces faits ne prouve que le code peut être déployé seul.

L'authentification est un piège courant. Elle paraît horizontale et autonome, mais chaque requête dépend de sa latence et de sa disponibilité. Ses données peuvent aussi mélanger identifiants, sessions, rôles, appartenance à un tenant, historique d'audit et parcours de récupération. Son extraction peut être justifiée, mais c'est une mauvaise répétition si une erreur de routage bloque toute l'entreprise.

Les données de référence partagées forment un autre piège. Un module de codes pays ou de catégories produits semble accessible en lecture seule jusqu'à ce que des administrateurs le modifient, que les caches se rafraîchissent à des moments différents et que les règles métier attendent un effet dans la même transaction. Le volume est faible, mais la diffusion immense. Un faible trafic ne signifie pas un faible risque de déploiement.

Le code de reporting paraît plus sûr parce que les rapports écrivent rarement les données centrales. Le coût caché vient de la propriété des requêtes. Un rapport qui joint trente tables du monolithe ne devient pas indépendant lorsqu'un point de terminaison HTTP enveloppe le même SQL. Il devient un service de requête distant lié à chaque schéma lu. L'extraction d'une projection de reporting fonctionne après avoir défini son flux et accepté un délai. Extraire les jointures existantes ajoute seulement un saut réseau.

Je déconseille la recommandation «extrayez d'abord le module le plus facile». Elle plaît parce qu'une séparation rapide du dépôt produit un progrès visible et offre un nouveau pipeline de déploiement. Elle est fausse quand la facilité ne concerne que le déplacement du code. Choisissez la responsabilité la plus facile à exploiter seule, avec ses données, ses pannes, son déploiement, son observation et son retour. Cette définition produit moins de mise en scène et plus d'apprentissage.

Le risque de déploiement compte plus que la taille du service

Un petit service peut avoir un vaste rayon d'impact, tandis qu'un worker asynchrone plus grand peut échouer discrètement puis rattraper sa file. Classez la première extraction selon les conséquences d'une mauvaise version. Le volume de code est un indicateur médiocre. La part des requêtes critiques qui franchit la frontière est bien plus révélatrice.

Préférez un candidat hors du chemin synchrone de la connexion, du paiement, de l'autorisation ou de la modification principale. L'envoi de notifications, la conversion de fichiers, la génération d'exports et l'indexation de documents sont souvent de meilleurs choix, car le monolithe peut mettre le travail en file et continuer. Cela ne les rend pas jetables. L'équipe gagne du temps pour observer, réessayer et réparer sans transformer chaque panne du service en panne générale.

Examinez aussi le couplage des ressources. Un nouveau processus peut surcharger la même base avec un autre pool de connexions, relancer une requête lente plus agressivement ou épuiser une file partagée. Une séparation sur un schéma de déploiement n'isole ni le processeur, ni les verrous, ni les connexions, ni les quotas en aval. Limitez explicitement la concurrence et les nouvelles tentatives avant de déplacer le trafic.

Évaluez chaque candidat à partir de conséquences compréhensibles par les opérateurs:

• Un arrêt de dix minutes est moins risqué si le travail attend puis reprend; l'échec des requêtes principales est un signal d'alerte.
• Une seule composante doit écrire les données de référence; plusieurs applications et tâches sont un signal d'alerte.
• Une clé d'idempotence stable sécurise les nouvelles tentatives; la répétition aveugle est un signal d'alerte.
• Un changement de route ou de consommateur doit ramener une version; fusionner les données et le schéma est un signal d'alerte.
• Les sorties comparées et mesures métier doivent détecter une erreur sémantique; l'état du processus seul est un signal d'alerte.

Ne transformez pas ce tableau en fausse formule numérique. Une note de 17 n'annule pas une réponse disant «nous ne pouvons pas reconstruire les écritures manquantes». Servez-vous-en pour exposer les conditions éliminatoires et imposer une discussion explicite. Pour une première extraction, une divergence de données irréversible est éliminatoire. Une dépendance qui impose de déployer tous les appelants dans la même fenêtre l'est aussi.

Définissez le contrat avant de déplacer l'implémentation

Le contrat d'extraction doit décrire le comportement face aux nouvelles tentatives, entrées périmées, doublons, délais et pannes partielles. Une liste de points de terminaison et de champs ne suffit pas. Les appelants doivent savoir quelle identité de requête reste stable, quelle transition est permise et quelle réponse signifie que le service a durablement accepté la responsabilité.

Écrivez le contrat d'après le comportement existant, même lorsqu'il déplaît. Si le monolithe accepte les soumissions dupliquées et renvoie la tâche d'origine, le nouveau service ne peut pas répondre par un conflit au prétexte que ce serait plus propre. Modernisez après avoir rendu la parité visible, ou derrière une modification explicitement versionnée. Sinon, chaque écart devient une dispute sur l'intention de l'ancien ou du nouveau résultat.

Pour une tâche d'export, une requête minimale rend la nouvelle tentative concrète:

{
  "request_id": "01JEXAMPLE8M4Q2",
  "account_id": "A1842",
  "report_type": "ledger",
  "cutoff": "2026-08-01T00:00:00Z"
}

Le service stocke request_id sous une contrainte unique avant de commencer. Une répétition renvoie la tâche existante et son état actuel. Un délai dépassé après acceptation devient récupérable: l'appelant répète la même identité au lieu d'inventer une autre tâche. Le contrat doit aussi définir un état d'échec terminal et préciser si un opérateur peut réessayer avec la même identité.

Décrivez les erreurs par l'action attendue de l'appelant. «Date de coupure incorrecte, ne pas réessayer» est utile. «Dépendance indisponible, réessayer avec une attente bornée» est utile. Une erreur interne générique pousse chaque appelant vers la réaction la plus dangereuse, la répétition aveugle immédiate. Fixez tailles et délais des requêtes dans le contrat, sinon la plus grande entrée historique découvrira ces limites en production.

Gardez la première interface plus petite que l'ancienne API interne. N'exposez pas les tables par des points génériques de création, lecture, modification et suppression. Proposez des opérations qui préservent les invariants, comme request_export, cancel_pending_export et get_export_status. Une surface de commandes étroite permet de changer l'implémentation sans coordonner à nouveau tous les appelants.

Un seul auteur évite les données en double autorité

La migration doit déclarer le moment où le nouveau service devient l'unique auteur de ses enregistrements. Une double écriture dans le code applicatif n'est pas une passerelle sûre. Une écriture peut réussir tandis que l'autre expire, et l'appelant ignore si une nouvelle tentative réparera ou dupliquera l'état.

Transférez la propriété par étapes. Rendez d'abord visibles les auteurs cachés et faites-les passer par une interface unique du monolithe. Ajoutez ensuite des identités stables et enregistrez l'ancien comportement. Laissez le nouveau service traiter une copie du trafic sans publier ses résultats. Après validation de la parité, routez les écritures de référence vers le service pendant que le monolithe lit par un chemin de compatibilité. Supprimez l'ancien auteur après la fermeture de la fenêtre de repli. C'est une seule séquence de migration, pas cinq projets indépendants.

Si le monolithe doit réagir à un changement validé par le service, publiez un événement dans la même transaction que ce changement. Une boîte d'envoi transactionnelle est le mécanisme habituel: le service valide ensemble l'état métier et une ligne de boîte, puis un relais publie cette ligne. Les consommateurs doivent toujours gérer les doublons, car le relais peut publier puis tomber avant de marquer la ligne comme terminée.

Évitez les clés étrangères entre services. Elles ne peuvent pas imposer l'intégrité entre bases séparées, et conserver une base commune maintient les déploiements couplés. Transportez l'identifiant référencé, validez-le quand le processus l'exige et décidez comment traiter suppression et copies périmées. Certains invariants demandent une vérification synchrone auprès de l'autorité, d'autres acceptent une projection locale. Cette décision appartient au contrat métier, pas à une jointure accidentelle.

Le chargement initial des données demande un repère et une requête de rapprochement. «Copier la table, puis basculer» laisse une course entre l'instantané et les écritures actives. Capturez les changements après une position connue, chargez l'instantané, appliquez les changements dans l'ordre et comparez les comptes avec les totaux métier ou les empreintes. Un même nombre de lignes ne détecte ni valeurs inversées, ni relations absentes, ni valeur par défaut dont le sens a changé.

Le plan de bascule doit nommer l'ancienne et la nouvelle autorité à chaque phase. Si le responsable d'incident doit déduire la propriété des tableaux de bord pendant que les écritures continuent, le plan a déjà échoué.

Le trafic fantôme doit comparer le sens

Un déploiement fantôme apporte plus de preuves lorsqu'il compare les résultats métier plutôt que les seuls codes de statut. Envoyez une copie des requêtes de production admissibles au nouveau service, isolez ses effets et enregistrez les sorties normalisées des deux implémentations. Classez ensuite les écarts par champ et règle métier.

Normalisez les valeurs non déterministes avant la comparaison. Horodatages, identifiants générés, collections non ordonnées et formatage peuvent varier sans modifier le comportement. Ne masquez pas les champs porteurs de sens, comme l'arrondi monétaire, les décisions d'autorisation, l'ordre promis à l'appelant ou le moment d'une transition. Chaque règle de normalisation doit avoir un responsable et une raison.

Le trafic de production enregistré trouve des combinaisons absentes des fixtures, mais il transporte aussi des données sensibles et des accidents historiques. Définissez conservation, accès, masquage et contrôles de rejeu avant la collecte. Dans un environnement réglementé, maintenir le banc dans le périmètre du client peut compter davantage que la commodité d'un système hébergé. Prendre en charge cet environnement ne donne pas une certification de conformité. Ce sont deux affirmations distinctes.

Comparez les effets au moyen d'un collecteur au lieu de laisser le service fantôme envoyer de vrais courriels, débiter un compte ou publier des événements faisant autorité. Remplacez ces adaptateurs par des enregistreurs d'intention. La comparaison utile est «la nouvelle implémentation aurait émis cet événement avec ces champs», pas «le gestionnaire a renvoyé 202».

Définissez les portes de promotion autour du comportement observé. Couvrez volume normal, charges maximales, nouvelles tentatives, entrées invalides, délais de dépendance et tâches planifiées trouvées pendant l'analyse du couplage. Exigez zéro différence inexpliquée pour les invariants touchant argent, autorisations ou état durable. Pour le formatage cosmétique, documentez les différences acceptées au lieu de prétendre viser l'égalité octet par octet.

CodeHero utilise un banc de parité face au trafic de production enregistré lorsqu'il réécrit un ancien système. J'exigerais cette partie même si une autre équipe construisait le remplacement. L'état du processus montre que le nouveau code tourne. Les preuves de parité montrent s'il accomplit toujours le travail.

Le retour doit changer le routage, pas réparer l'historique

Un retour sûr arrête le nouveau trafic vers le service extrait sans demander aux opérateurs de fusionner deux historiques contradictoires. Cette propriété doit être conçue avant la bascule. Si le retour exige de transformer les données à l'envers, de restaurer une table partagée ou de redéployer tous les appelants, il sera trop lent face à une panne ambiguë.

Gardez l'ancien chemin de lecture pendant la fenêtre d'observation, mais pas deux auteurs sans contraintes. Lorsque le nouveau service possède les écritures, retransmettez ses changements validés vers le stockage de compatibilité du monolithe ou faites lire le monolithe à travers le service. La première option permet un repli rapide des lectures si le retard de réplication est visible. La seconde conserve une vérité unique, mais ajoute la disponibilité du service à l'ancien chemin. Choisissez selon l'arrêt que vous pouvez supporter.

Utilisez un contrôle de route indépendant du déploiement applicatif. Il peut se trouver à la passerelle, dans une affectation de consommateur ou derrière un paramètre côté serveur. Protégez-le par un contrôle d'accès et une piste d'audit. Testez le retour exact sous charge avant la bascule, avec les requêtes en cours et les messages en file.

Définissez les déclencheurs du retour avec des observations. Une hausse du taux d'erreur manque les corruptions sémantiques. Incluez les écarts de parité, l'âge de la file, le taux de doublons, les transitions refusées et les totaux métier. Nommez la personne autorisée à revenir et celle qui diagnostique après le déplacement du trafic. Une réunion d'urgence ne remplace pas un plan de commande.

Les modifications de schéma doivent rester compatibles pendant la fenêtre de retour. Ajoutez les champs avant de les rendre obligatoires, acceptez anciennes et nouvelles représentations pendant la coexistence des versions, puis supprimez les anciens champs. Les scripts de retour de base rassurent sur le papier, mais inverser une migration destructive après de nouvelles écritures est souvent impossible. Les changements compatibles vers l'avant préservent la possibilité de rerouter.

Ne qualifiez pas chaque recul d'échec. Si le changement de route fonctionne, que les preuves restent intactes et que l'équipe trouve un écart sémantique avant que les clients en dépendent, le mécanisme d'extraction a rempli son rôle. L'échec consiste à découvrir qu'une modification improvisée des données est le seul chemin de retour.

La promotion exige des responsables, des seuils et une horloge

Une bascule est prête lorsque des personnes nommées peuvent décider, à partir des preuves actuelles, de continuer, suspendre ou revenir. Une invitation et un tableau de bord ne donnent pas cette capacité. L'équipe a besoin d'un relevé d'exploitation qui relie chaque signal à une action et chaque action à un rôle responsable.

Rédigez une fiche de promotion avant le trafic fantôme. Nommez la version candidate, le contrôle de route, le repère de données, le mode de compatibilité, la profondeur attendue de la file, la variation de latence permise, les règles de parité et la personne autorisée à déplacer le trafic. Inscrivez les commandes ou actions exactes de chaque palier et du retour. Si la procédure dépend du souvenir d'un paramètre non documenté par un seul ingénieur, répétez-la jusqu'à supprimer cette dépendance.

Déplacez le trafic par paliers qui révèlent les effets de charge sans créer une nouvelle autorité de données à chaque étape. Un pourcentage peut suffire pour les lectures sans état. Pour le travail avec état, routez selon une partition stable comme l'identifiant de compte, le type de tâche ou le tenant afin qu'une unité ne saute pas entre implémentations. Conservez cette affectation. Un pourcentage aléatoire sur des écritures liées peut partager un processus entre deux propriétaires et rendre la panne intermittente.

Le temps intervient de deux façons. Le nouveau service doit voir assez de travail représentatif, et chaque palier doit avoir une durée maximale avant une décision explicite. Un déploiement partiel sans fin peut devenir une architecture permanente avec deux tableaux de bord, deux procédures et aucun propriétaire clair. Réglez la décision sur les rythmes de trafic, pas sur la patience de la direction. Un service avec un traitement quotidien important doit le voir avant promotion. Pour un chemin de fin de trimestre, un rejeu enregistré évite une attente déraisonnable.

Séparez les seuils d'infrastructure des seuils sémantiques. Saturation processeur, épuisement des connexions, croissance de la file et délais indiquent si le service tient la charge. Totaux d'état, nombre de transitions, arrondis, décisions d'autorisation et effets prévus indiquent s'il tient le bon comportement. Une version rapide et fausse doit s'arrêter plus tôt qu'une version temporairement lente et correcte.

Utilisez un relevé de décision compact pendant le déploiement:

1. Le responsable de version note la partition de trafic et le repère de données avant de modifier la route.
2. L'observateur confirme les signaux d'infrastructure et les résultats de parité sur cette partition.
3. Le responsable métier classe chaque nouvel écart sémantique comme expliqué, bloquant ou accepté avec une raison écrite.
4. Le responsable d'incident confirme que le retour reste possible avec le schéma actuel et le travail en attente.
5. Le responsable de version promeut, suspend ou revient, puis consigne les preuves utilisées.

Ce n'est pas une cérémonie gratuite. Ce relevé évite un incident familier: l'infrastructure paraît saine, le déploiement avance et un écart métier inexpliqué attend l'équipe suivante parce que personne ne peut bloquer la promotion. Il rend l'incertitude visible pendant que le retour reste peu coûteux.

Gardez une horloge pour la reprise technique et une autre pour les données. Le retour de route peut prendre quelques secondes, tandis que rejouer des événements manqués ou reconstruire une projection prend plus longtemps. Énoncez les deux objectifs. Déclarer le retour terminé dès que les requêtes rejoignent le monolithe masque les réparations en cours et incite à supprimer les preuves trop tôt.

La promotion se termine après le nettoyage de la propriété. Supprimez les doubles chemins de lecture temporaires, retirez les droits de base obsolètes, archivez les comparaisons selon la politique convenue, puis mettez à jour le catalogue et l'astreinte. Des droits de migration laissés en place transforment un pont contrôlé en interface permanente officieuse. La prochaine extraction doit commencer avec moins de chemins cachés.

La première extraction teste le système de migration

Le premier service réussit quand l'organisation peut répéter la méthode avec de meilleures preuves et moins de coordination. Sa valeur métier compte, mais il produit aussi un système de migration testé: découverte des dépendances, capture du contrat, rejeu du trafic, transfert des données, portes de promotion et routage réversible.

Notez où le plan contredisait la production. Une procédure stockée possédait peut-être une écriture absente de la recherche. Les nouvelles tentatives ne réutilisaient peut-être aucun identifiant. La plus grande charge venait peut-être d'une tâche trimestrielle. Transformez chaque surprise en requête automatisée, trace ou porte pour le candidat suivant. Une rétrospective sans contrôle modifié ne conserve que l'anecdote.

Gardez le nouveau service indépendant après son lancement. Donnez-lui son propre artefact déployable, ses signaux techniques et métier, des limites de ressources, une astreinte et une procédure pour les tâches bloquées. N'exigez pas une version du monolithe pour changer son implémentation. Ne laissez pas sa base devenir un schéma de reporting pratique pour de nouveaux consommateurs. Chaque lecteur direct crée un futur problème d'extraction.

La modernisation de l'architecture doit suivre le comportement observé plutôt que transposer les anciens modules dans de nouveaux processus. Une analyse de tout le code aide, car le comportement historique traverse souvent langages, procédures stockées, fichiers batch et code client. CodeHero lit ces sources ensemble et livre les réécritures en moins de 30 jours, mais la vitesse ne dispense ni de nommer un propriétaire des données ni de tester le retour.

Choisissez le candidat dont la panne reste contenue, dont les écritures peuvent avoir un seul propriétaire et dont les appelants supportent une frontière réseau sans transaction distribuée. Prouvez-le avec du trafic enregistré et ramenez la route une fois avant la vraie bascule. Une équipe qui n'a jamais exécuté le retour possède un document de retour, pas une capacité de retour.