Idempotent Receiver

La défense côté receiver : faire en sorte qu'un message reçu deux fois ne produit qu'un effet métier — distinct des garanties producer.

Problème

Un broker EDI livre at-least-once. Un partenaire retransmet par prudence un même DESADV après n'avoir pas reçu son MDN. Comment éviter de comptabiliser deux fois la réception ?

Forces

• Un opérateur consciencieux retransmet préventivement — l'arrivée double est normale.
• Le receiver n'a pas toujours la main sur la couche transport pour éliminer les doublons en amont.
• Un Idempotency table consommée par le receiver doit avoir un schéma stable et une politique de purge.
• Détecter un doublon coûte une lookup en DB — la latence augmente.

Solution

Le receiver implémente une déduplication par message identifier (UNB control reference, ISA13, AS4 MessageId). À la réception, il consulte une `idempotency_keys` table : si la clé existe, il acquitte mais ne re-déclenche pas le traitement métier. Sinon il insère la clé en transaction avec le traitement (UPSERT atomique). La table est purgée selon un TTL (24h, 7j, 30j selon le flow).

Implémentation EDI

En EDI, le pattern est crucial côté hub partagé. Walmart MDN policies imposent re-retry au bout de 5 min sans MDN — un consumer naïf comptabiliserait un même DESADV deux fois en réception. La table idempotency utilise (`partner_id`, `message_id`) comme PK composite, et un index sur `received_at` pour la purge. Sur Kafka, l'idempotency au niveau du consumer complète la idempotency du producer (`enable.idempotence=true`) qui ne couvre que la transmission, pas la sémantique métier.

Anti-patterns

• Idempotency key dérivée du timestamp — deux retransmissions à 1 sec d'écart sont vues distinctes.
• Pas de TTL — la table grossit indéfiniment et la lookup ralentit.
• Lookup hors transaction — race condition entre check et insert.
• Idempotency seulement côté producer — un crash du producer entre send et commit en DB introduit des doublons que seul le receiver peut filtrer.

Patterns liés

• Idempotence (producer) — pendant côté émetteur.
• Message Store — support de l'idempotency table.
• Transactional Client — écriture transactionnelle.

Sources

• Hohpe G., Woolf B. — EIP, Idempotent Receiver (p. 528). www.enterpriseintegrationpatterns.com/patterns/messaging/IdempotentReceiver.html
• Microsoft — Idempotent message processing. learn.microsoft.com/en-us/azure/architecture/reference-architectures/event-hubs/