Guaranteed Delivery

L'assurance qu'aucun message ne se perd même si un broker crash.

Problème

Un broker en mémoire perd ses messages au reboot. En EDI, perdre un INVOIC = perdre une trace fiscale = audit échec. Comment garantir la durabilité ?

Forces

• Performance vs durabilité — fsync à chaque write coûte cher.
• Réplication vs disponibilité — un broker répliqué tient le crash mais ajoute de la latence.
• EDI contient des messages à valeur juridique — INVOIC fiscaux 10 ans, MDN signés non-répudiables.
• Le producteur veut un ACK rapide — sinon il retransmet (et la déduplication doit gérer).

Solution

Configurer le broker (Kafka, RabbitMQ, IBM MQ) en mode persistant avec réplication ≥ 3, fsync sync ou async selon SLA, et acks=all côté producteur. Le broker n'acquitte le message que quand au moins N replicas l'ont écrit sur disque. La perte d'un broker (jusqu'à N-1) n'entraîne aucune perte de message.

Implémentation EDI

En EDI, configuration Kafka recommandée : min.insync.replicas=2, replication.factor=3, acks=all, producer retries=infinite. Sur Apache MQ : persistent=true, transactional=true. Pour AS2/AS4 : confirmation MDN signé après écriture en base = guaranteed delivery applicatif. Coût typique : +20-30 ms de latence vs in-memory.

Anti-patterns

• acks=1 sur Kafka — perte possible si le leader crash avant réplication.
• min.insync.replicas=1 — équivalent de pas de réplication.
• Persister le message en base mais pas dans le broker — incohérence si l'app crash entre les deux.

Patterns liés

• Message Store — persistance applicative complémentaire.
• Idempotence — protège des retransmissions.
• Transactional Client — producteur transactionnel.

Sources

• Hohpe G., Woolf B. — EIP, Guaranteed Delivery (p. 122). www.enterpriseintegrationpatterns.com/patterns/messaging/GuaranteedMessaging.html
• Confluent — Kafka durability docs. docs.confluent.io/platform/current/installation/configuration/producer-configs.html