Un flux de commande couvre les paiements, le stock et l'expédition, chacun avec sa propre base de données. Comment gardez-vous l'ensemble cohérent ?

Vous renoncez à une transaction distribuée unique et vous utilisez une saga : une séquence de transactions locales où chaque étape publie un événement qui déclenche la suivante, et chaque étape a une action de compensation pour l'annuler. La cohérence devient éventuelle, donc le travail de conception consiste à décider quoi compenser, quoi rejouer et quoi escalader vers un humain. Modélisez le flux explicitement, soit par chorégraphie via des événements, soit coordonné par un orchestrateur.

Un commit à deux phases entre trois services et trois bases signifie tenir des verrous à travers le réseau et un coordinateur qui peut tout bloquer s'il meurt, donc je ne le ferais pas. À la place, le flux devient une saga. Chaque service fait sa propre transaction locale et émet un événement, et chaque étape a une compensation définie : si l'expédition ne peut pas allouer, on libère la réservation de stock et on rembourse ou on annule le paiement. L'important, c'est que la compensation est une action métier, pas une annulation technique ; un remboursement laisse une trace visible et c'est correct. Pour tout ce qui dépasse environ trois étapes, j'utilise un orchestrateur plutôt qu'une chorégraphie pure, parce qu'en chorégraphie le flux réel n'existe nulle part et personne ne peut dire où une commande est bloquée. Un orchestrateur me donne une seule machine à états, des délais par étape et un statut interrogeable. Chaque étape est idempotente et rejouée avec backoff, et tout ce qui épuise ses reprises atterrit dans une file d'exploitation avec l'identifiant de commande, parce que certains échecs ont vraiment besoin d'une personne.