Outbox (architectural)

La table tampon qui transforme deux écritures non-coordonnées (DB + broker) en une écriture atomique côté DB.

Problème

Sans XA broker (Kafka), comment garantir qu'un side effect métier (création d'une commande) et son message publié au broker arrivent tous deux ou aucun — sans verrouiller l'application en cas de broker down ?

Forces

• Une écriture broker pendant une transaction DB n'est pas transactionnelle.
• Un broker down ne doit pas bloquer la prise de commande dans l'application.
• Un retry de publication doit être idempotent côté broker.
• Le poller doit avoir un throughput suffisant pour ne pas accumuler le backlog.

Solution

Créer une table `outbox` (id, aggregate_type, aggregate_id, payload, status, created_at). Le producer insère son message dans `outbox` au sein de la même transaction que les modifications métier (un seul COMMIT). Un poller dédié — souvent Debezium CDC sur la table outbox — lit les nouvelles lignes et publie sur le broker. À publication réussie, status passe à `SENT`. À échec, retry avec backoff. La PK ou un message_id stable assure l'idempotence côté broker.

Implémentation EDI

En EDI, l'Outbox est le pattern dominant pour relier ERP → Kafka EDI hub. L'ERP insère l'event 'OrderConfirmed' dans `outbox` au sein de la transaction qui confirme la commande. Debezium reads PostgreSQL WAL, publie sur `edi.orders.confirmed`. Le hub EDI consomme et émet l'ORDRSP au partenaire. Bonus : la table outbox sert aussi de message store pour rejeu et audit — utile en cas d'incident d'export du broker.

Anti-patterns

• Outbox sans index sur status / created_at — le poller scan toute la table à chaque cycle.
• Outbox sans purge — la table gonfle indéfiniment et ralentit le poller.
• Outbox sans idempotency message_id — un retry duplique le message côté broker.
• Poller mono-threadé avec un haut throughput — le poller devient le bottleneck.

Patterns liés

• Transactional Client — abstraction code correspondante.
• Transactional Channel — concept topologique parent.
• Change Data Capture — mécanisme typique du poller.
• Guaranteed Delivery — objectif global.

Sources

• Microsoft Azure Architecture — Outbox pattern. learn.microsoft.com/en-us/azure/architecture/patterns/outbox
• Debezium — Outbox event router. debezium.io/documentation/reference/transformations/outbox-event-router.html