Transactional Client

L'atomicité métier ↔ messaging — la garantie 'message envoyé si et seulement si DB committée'.

Problème

Une application traite un PO entrant : (1) écrit en base, (2) envoie un ACK 855 sortant. Que faire si (1) réussit mais (2) échoue ? Réessayer (1) re-crée le PO. Le partenaire attend l'ACK en vain.

Forces

• Une transaction atomique entre messaging et DB demande un protocole 2PC ou un pattern alternatif.
• 2PC est lent et fragile.
• Ne rien faire entraîne des incohérences observées en prod.
• Le pattern Outbox (alternative moderne) résout sans 2PC mais ajoute de la latence.

Solution

Deux options : (a) protocol XA / 2PC entre broker et DB, peu utilisé en pratique pour son coût ; (b) Outbox pattern : la transaction DB inclut l'écriture du message dans une table 'outbox', un worker async lit cette table et publie sur le broker. Le Transactional Client garantit que message et DB-state sont cohérents — soit les deux, soit aucun.

Implémentation EDI

En EDI moderne, l'implémentation dominante est Outbox : INSERT INTO outbox_table (msg_id, payload, status='pending') dans la même transaction que l'INSERT INTO orders. Un worker Debezium / CDC consomme la table, publie dans Kafka, marque status='sent'. Garantit l'atomicité métier+messaging sans 2PC.

Anti-patterns

• Send-then-DB (envoyer avant de committer) — risque double-traitement si le commit échoue.
• DB-then-send sans Outbox — risque de message perdu si l'app crash entre.
• 2PC entre Kafka et Postgres — coût opérationnel trop élevé pour les volumes EDI.

Patterns liés

• Guaranteed Delivery — garantie côté broker.
• Idempotence — protège des doublons.

Sources

• Hohpe G., Woolf B. — EIP, Transactional Client (p. 484). www.enterpriseintegrationpatterns.com/patterns/messaging/TransactionalClient.html
• Microservices.io — Transactional Outbox. microservices.io/patterns/data/transactional-outbox.html