Transactions distribuées : comprendre le pattern Inbox / Outbox
Le pattern Inbox / Outbox permet de rendre les intégrations asynchrones plus fiables sans dépendance à une transaction distribuée globale.
Dans un système distribué, une opération métier implique souvent plusieurs effets:
- écriture en base
- publication d'un événement
- appel d'un autre service
Le problème apparaît quand l'un réussit et l'autre échoue. La base est mise à jour, mais le message n'est jamais envoyé. Ou l'inverse.
Le pattern Inbox / Outbox est une réponse pragmatique à ce problème.
L'idée de l'Outbox
Au lieu d'écrire en base puis publier un message de manière séparée, l'application:
- enregistre les données métier
- enregistre aussi le message à publier dans une table Outbox
- valide le tout dans la même transaction locale
Ensuite, un processus distinct lit l'Outbox et publie les messages.
Le bénéfice est clair: la vérité transactionnelle est conservée dans la base applicative.
L'idée de l'Inbox
Du côté consommateur, l'Inbox sert à enregistrer les messages déjà traités pour éviter:
- les doublons
- les replays dangereux
- les effets de bord non idempotents
Chaque message reçu est marqué comme traité avec une clé unique.
Pourquoi ce pattern reste pertinent
Le pattern Inbox / Outbox permet:
- d'éviter une transaction distribuée globale
- de fiabiliser les événements
- de rendre les retries plus surs
- d'améliorer l'idempotence
Il ne supprime pas toute la complexité, mais il la rend gérable.
Conclusion
Inbox / Outbox n'est pas un pattern « avancé » réservé aux architectures exotiques. C'est un mécanisme de fiabilité très utile dès qu'une application doit synchroniser état métier et messaging sans perdre en cohérence.
