Refonte d’un monolithe grand compte mondial et accélération de la vérification

Le goulot d’étranglement : une requête de dix minutes

Le coût de cette conception n’était pas les dix minutes elles-mêmes — c’était ce que ces dix minutes occupaient. Chaque vérification monopolisait un thread de requête pendant toute sa durée : une hausse modeste de vérifications simultanées suffisait à épuiser les workers disponibles et à laisser le reste de l’application en file derrière un travail qui ne la concernait pas. Des utilisateurs qui n’avaient jamais touché à la vérification voyaient toute la plateforme ralentir.

Le second coût portait sur la justesse. Les enregistrements impliqués dans une vérification restaient verrouillés pendant la génération : un processus qui échouait à mi-parcours laissait des lignes bloquées et un travail inachevé, sans moyen sûr de le relancer — réexécuter risquait d’émettre un second exemplaire d’un document déjà généré.

L’architecture : un travail idempotent, sorti du chemin de la requête

J’ai découplé la génération synchrone en un pipeline de tâches asynchrones idempotentes. J’ai mené une transition par phases de 11 mois vers des services modernes en maintenant la production disponible sans interruption.

Sortir la génération du chemin de la requête est la moitié évidente de cette phrase. Celle qui décide si cela fonctionne, c’est l’idempotence. Le travail asynchrone est un travail réessayé — un job qui échoue, expire ou est redélivré sera réexécuté — donc chaque unité de travail devait pouvoir s’exécuter deux fois sans dommage. Donner à chaque job une clé telle qu’une répétition produise le même résultat plutôt qu’un second document est ce qui a rendu la livraison at-least-once acceptable, et ce qui a transformé un échec partiel d’incident en simple reprise.

La migration elle-même était la contrainte la plus dure. La plateforme servait des marques grands comptes mondiales et ne pouvait pas être arrêtée pour une bascule : les services de remplacement ont donc été déployés à côté du monolithe et ont repris les responsabilités progressivement, un chemin à la fois, le code d’origine restant en place jusqu’à ce que son remplaçant ait fait ses preuves sous trafic de production réel.

Le résultat

La vérification est passée de 10 minutes à 50 secondes — une latence divisée par 12 — et la couche web a cessé d’absorber le coût d’un travail qui n’avait jamais eu sa place sur le chemin de la requête. La disponibilité de la plateforme s’est maintenue à 99,9 % pendant toute la transition, avec zéro interruption de service.

Le résultat durable est moins visible que le chiffre de latence. Les échecs de vérification sont devenus rejouables au lieu d’exiger une reprise manuelle, et livrer des changements sur ce chemin n’a plus nécessité de fenêtre de maintenance.