Dead-Letter Queue : variantes et runbooks
Le Dead Letter Channel d'EIP §119 est trop monolithique pour un hub EDI 2026. Cinq variantes opérationnelles — retry étagé, parking lot, dead-letter par cause, sonde de fuite, runbook de retraitement — séparent ce qui est récupérable de ce qui ne l'est pas.
Problème
Une DLQ unique transforme rapidement en cimetière : des messages s'y accumulent sans triage, sans priorisation, sans contexte. L'équipe ops ouvre le ticket « 127 erreurs en DLQ », doit deviner cas par cas si c'est une indisponibilité réseau (à réessayer), un schéma cassé (à corriger), un payload corrompu (à supprimer), ou une attaque (à investiguer). Sans structure, le temps moyen de résolution explose. La règle : une DLQ unique fonctionne pour 100 messages/jour, pas pour 10 000.
Forces
- Typologie d'erreurs : transient (réseau, partenaire down), permanent (schéma cassé, payload corrompu), métier (validation business), sécurité (signature invalide).
- Sondes de fuite : une croissance soudaine de la DLQ est le signal le plus fiable d'un problème production — doit déclencher alerte.
- Coûts d'erreur asymétriques : laisser un faux positif (message rejeté à tort) coûte 100x plus qu'un faux négatif (retry inutile).
- Conformité : les messages en DLQ contiennent souvent des données métier — leur retention est encadrée (RGPD, archivage fiscal).
- Idempotence du retraitement : replay un message DLQ ne doit pas créer de doublon si le partenaire a déjà retransmis entretemps.
Solution
Mettre en place cinq variantes en couches :
- Retry étagé : queues intermédiaires
retry-5s,retry-30s,retry-5min,retry-30min,retry-2havec backoff exponentiel. Échec après 5 retries → DLQ. - DLQ par cause :
dlq-schema-error,dlq-business-validation,dlq-partner-rejected,dlq-signature-invalid,dlq-unknown. Routage selon le type d'exception capturé. - Parking lot queue : pour messages que les ops décident de garder mais ne savent pas encore quoi en faire (en attente d'arbitrage business).
- Sonde de fuite : alerte si la profondeur d'une DLQ augmente de plus de 10 messages en 5 min, ou si le rate dlq/total dépasse 0,1 %.
- Runbook de retraitement : outil CLI/UI qui permet de filtrer, inspecter, modifier (avec audit), retenter ou supprimer (avec audit) les messages DLQ.
Structure
Flow d'erreur en couches:
Producer ──► main-topic ──► consumer
│
▼ fail (transient)
retry-5s ──► consumer (attempt 2)
│
▼ fail
retry-30s ──► consumer (attempt 3)
│
▼ fail
retry-5min ──► ... attempt 5
│
▼ exhausted
┌── Classify error ──┐
│ │
▼ ▼
dlq-schema-error dlq-partner-rejected
│ │
▼ ▼
parking-lot ops-runbook-required
Sonde de fuite:
Prometheus alert: dlq_depth_5min_diff > 10Implémentation EDI
Sur Kafka, naming convention typique pour un hub EDI :
# Topology Kafka pour un flux EDI typique
edi.ingest → ingestion brute
edi.parse → parsing EDIFACT/X12/UBL
edi.parse.retry.5s → retry 5s après échec transient
edi.parse.retry.30s → retry 30s
edi.parse.retry.5min → retry 5min
edi.parse.dlq.schema → schema invalide (action: fixer mapping)
edi.parse.dlq.business → règle métier (action: review partenaire)
edi.parse.dlq.unknown → cause inconnue (action: investigation)
edi.parse.parking-lot → en attente décision business
# Headers Kafka enrichis sur le message en DLQ
x-original-topic: edi.parse
x-error-class: SchemaValidationException
x-error-msg: "Element 'UNH' missing"
x-retry-count: 5
x-first-failed-at: 2026-05-18T10:23:45Z
x-correlation-id: msg-abc-123
x-partner-id: WALMART
x-message-id: REF12345
# Spring Kafka error handler config (Java)
@Bean
public DefaultErrorHandler errorHandler(KafkaTemplate<String, Object> tpl) {
DeadLetterPublishingRecoverer recoverer = new DeadLetterPublishingRecoverer(
tpl,
(record, ex) -> {
if (ex instanceof SchemaValidationException) {
return new TopicPartition("edi.parse.dlq.schema", -1);
} else if (ex instanceof BusinessRuleException) {
return new TopicPartition("edi.parse.dlq.business", -1);
}
return new TopicPartition("edi.parse.dlq.unknown", -1);
});
return new DefaultErrorHandler(recoverer,
new ExponentialBackOffWithMaxRetries(5));
}
Runbook de retraitement (CLI minimaliste) : lister par partenaire et
cause (dlq inspect --topic dlq-schema --partner WALMART --since 2h),
inspecter un message (dlq show msg-abc-123), retenter en injectant
sur le main topic (dlq replay msg-abc-123 --to edi.parse), ou
supprimer avec audit (dlq drop msg-abc-123 --reason "payload corrompu,
partenaire prévenu ticket TKT-456"). Toute action génère un événement
audit immuable.
Anti-patterns
- Une DLQ unique pour tous les flux du hub — impossible à trier, le runbook devient inutilisable au-delà de 1 000 messages.
- Pas de TTL ni de purge DLQ — les anciens messages s'accumulent indéfiniment, performances broker dégradent, audit RGPD compromis.
- Replay automatique sans intervention ops — un crash silencieux qui réinjecte 100 000 messages corrompus en boucle.
- DLQ sans corrélation au message original (pas de correlation-id ni source-topic) — impossible de retrouver le contexte.
- Pas d'alerte sur croissance DLQ — la fuite est invisible jusqu'à ce que les ops la découvrent en regardant la console une fois par semaine.
Patterns liés
- Dead Letter Channel (EIP) — la version canonique du pattern.
- Invalid Message Channel — pattern complémentaire pour les messages bien formés mais sémantiquement invalides.
- Poison Message Handling — pattern pour les messages qui plantent systématiquement le consumer.
- Retry & Backoff — stratégie qui alimente la DLQ après exhaustion.
- Flux d'exception — vue d'ensemble de la gestion d'erreur en EDI.
Sources
- Hohpe G., Woolf B. — Enterprise Integration Patterns: Dead Letter Channel, Addison-Wesley 2003, §119. enterpriseintegrationpatterns.com
- AWS — Amazon SQS Dead-Letter Queues. La doc de référence du pattern multi-tier (main → DLQ). docs.aws.amazon.com
- Confluent — Error Handling Patterns in Kafka Streams, 2019. confluent.io
- Spring Kafka — Dead Letter Topics and Error Handlers. docs.spring.io
- Nygard M. — Release It! Design and Deploy Production-Ready Software, 2e éd. Pragmatic Bookshelf 2018, chap. 5 (« Stability Patterns »).