DLQ et traitement des messages toxiques

Dead Letter Queue (DLQ) est une file d'attente/pointe isolée pour les messages qui n'ont pas pu être traités par un consumer à temps plein après un certain nombre de tentatives ou pour des raisons techniques/commerciales évidentes (schéma non validé, temporisation, conflit de version, etc.). Message toxique (poison message) : Enregistrement dont le traitement répété échoue régulièrement et menace la stabilité de la pipline.

Objectif du DLQ : conserver le SLO, localiser la défaillance, empêcher le blocage du flux principal et garantir les capacités d'analyse et de reproduction sécurisée (redrave).

1) D'où viennent les messages toxiques

Schémas/contrats : modifications incompatibles, champs obligatoires manquants, types incorrects.
Validation d'entreprise : duplications, invariants perturbés, événements périmés.
Ordre et causalité : « Update » est arrivé à « Create », corrélations manquées, out-of-order.
Idempotence : le traitement répété donne lieu à des effets secondaires.
Dépendances externes : limites limitées/temporisation, indisponibilité de l'API.
Données : corruption de charge utile, codage incorrect, dépassement de taille.

2) Critères d'envoi au DLQ

• Le traitement maxAttempts est dépassé chez le consumer/worker.
• Erreur classée comme défectueuse (non-rétroactive) : schéma non validé, absence de ressource critique, interdiction d'activité.
• Le message deadline (TTL/expiration) a expiré.
• La stratégie circuit breaker ou admission control a fonctionné pour cette clé/tenante.
• Décision explicite de l'opérateur (« eject » manuel du flux principal).

3) Topologies et schémas DLQ

Per-queue DLQ : chaque file d'attente a son propre DLQ. Simple et transparent.
Central DLQ (parking lot) : un « parking » commun pour les cas complexes, pratique pour des outils d'analyse uniques.
DLT (Dead Letter Topic) : Pour les bus orientés journal (event log), un top séparé avec des métadonnées de cause de défaillance.
Quarantine : tampon de quarantaine avec accès rigide et assainissement par PII pour analyse manuelle.
Shadow-stream : dupliquer les messages problématiques en « shadow » pour des expériences de fix sécurisées.

4) Métadonnées qui doivent accompagner le DLQ

• Cause de l'échec : code/classe d'erreur, stack/trace id.
• Contexte des retraits : 'attempt', 'maxAttempts', 'first _ seen _ ts',' last _ attempt _ ts'.
• Corrélation : 'trace _ id', 'span _ id', 'tenant _ id', 'entity _ id', clé de lot.
• Offset/partition/sequence originale (pour les bus logiques) ou message-id.
• Contrat/schéma/version de la charge utile.
• Idempotency-key/Request-id (le cas échéant).
• Source de routage : nom de la file d'attente/topic, consumer-group.

5) Politiques rétrogrades à DLQ

• Courtes retraits consumer : 'maxAttempts' 2-5, backoff exponentiel + jitter, caps sur la concurrence.
• Backpressure coopérative : réduire la concurrence tout en augmentant les erreurs.
• Classification des erreurs : retryable ('5xx', timout) vs non-retryable (validation, schema mismatch).
• Files d'attente différées (delay queue) : 5s → 30s → 2m pour les pannes temporaires.
• Isolation par clé : si « bruite » une clé spécifique, ne bloquez pas l'ensemble du lot.

6) Sécurité Redrive (refoulement de DLQ)

Redrive est un retour contrôlé des messages du DLQ vers le traitement.

1. Vérification du fix : Redrave seulement après la correction du code/configuration/schéma ou après la restauration des dépendances externes.

2. Idempotence : Les manipulateurs doivent être résistants à la répétition (upsert, opérations à effet tolurant).

3. Déduplication : par 'idempotency _ key '/' message _ id'/' business _ key'.

4. Dosage et fenêtres : batches par N messages, rate-limit par drave, « fenêtres » par temps/lots.

5. Validation locale : vérification rapide du schéma avant la redrave (reject des premiers cas non valides).

6. Priorité : Redrive ne doit pas supplanter le trafic de vente (workers de faible priorité/pool séparé).

7. Observabilité : métriques et tracés distincts pour le drave ; rapport sur les résultats (succès/DLQ répété/perte).

7) La sémantique d'expédition et l'ordre

At-least-once est le mode le plus fréquent : l'idempotence et la déduplication sont nécessaires.
At-most-once - DLQ peut être désactivé ; risque de perte. Utilisez uniquement pour les pertes admissibles.
Exactly-once (efficace) : atteint par les transactions et le dédupit dans le stockage de l'entreprise ; cher et spécifique.
Ordre : DLQ rompt généralement l'ordre pour une clé/lot spécifique. Si l'ordre est critique, redravite par clé et séquentiellement.

8) Régimes, contrats et validation

Schema registry/contrats : versioning clair, évolution avec compatibilité backward/forward.
Validation à l'entrée : contrôle bon marché via JSON Schema/Protobuf/Avro avant les étapes difficiles.
Stratégie d'incompatibilité : si le champ « casser » est immédiatement dans le DLQ avec le code 'SCHEMA _ INCOMPATIBLE'.
Redaction PII : dans le DLQ, ne stockez que le nécessaire ; masquer les champs sensibles.

9) Idempotence et déduplication

Idempotency-key : formez sur le produit à partir du « sens des affaires » (tenant + entity + opération + ts-bucket).
Logs dedup : Stockez les dernières clés 'N'avec la TTL ; Mémorisez « l'effet » de l'opération.
Upsert/merge : éviter « insert-only » sans restrictions.
Side effects : pour les appels externes - journalisez et vérifiez la « répétition » avant d'appeler.

10) Observabilité et SLO

• Taux de DLQ (msg/s), proportion de messages, « âge » moyen/médian dans le DLQ.
• Succès de Redrive (%), part de DLQ répétée.
• Classification des causes : schema, validation, timeout, dependency, unknown.
• p95/p99 latence de traitement du flux principal vs dans le redrave.
• Taille DLQ, risque de débordement.

• Balises obligatoires : 'message _ id', 'entity _ id', 'tenant _ id', 'attempt', 'reason', 'redrive _ batch _ id'.
• Tracer la « branche DLQ » : de la source au succès répété.

• Proportion de messages traités avec succès ≥ X % par T minutes.
• Temps d'enquête et de correction pour la case DLQ ≤ Y heures.
• L'âge maximal du message dans le DLQ ≤ Z heures (avec alert).

11) Sécurité et conformité

Accès selon le principe des plus petits privilèges : redrave - opérateurs/playbooks uniquement.
Audit : qui et quand a déclenché la suppression/modification des métadonnées.
Assainissement : lorsque vous transférez vers le DLQ central, supprimez les PII/secrets superflus.
Retraite : durée de conservation séparée et politique d'élimination pour le DLQ.

12) Multi-ténacité

Balises 'tenant _ id/plan' : distinguez les limites, les priorités, les rapports.
DLQ ou partis per-tenants : qu'un client « bruyant » ne marque pas un DLQ général.
Facturation/quotas : tenez compte du volume de DLQ et de la valeur de redrave dans l'utilisation.

13) Modèles de configuration (exemple)

yaml consumer:
max_attempts: 4 backoff:
strategy: exponential_full_jitter initial_ms: 200 max_ms: 5000 classify_errors:
retryable:  [TIMEOUT, DEP_UNAVAILABLE, 5xx]
nonretryable:[SCHEMA_INCOMPATIBLE, VALIDATION_FAILED, DUPLICATE]
concurrency_caps:
per_partition: 8 per_tenant: 50

dlq:
type: topic name: myapp. events. dlq metadata:
include: [reason, stack, attempt, first_seen_ts, last_attempt_ts, schema_version,
tenant_id, entity_id, trace_id, source_topic, partition, offset]
retention_hours: 168 pii_redaction: true

redrive:
mode: batch batch_size: 500 rate_limit_per_sec: 50 priority: low validate_schema_before_redrive: true idempotency:
dedup_ttl_hours: 24 ordering:
by_key: true

14) Playbooks opérationnels (runbooks)

1. Croissance anormale du DLQ : activer le throttling pro-consumer, analyser les causes principales, vérifier les versions/schémas.
2. Schema mismatch : retour/verrouillage du schéma, migration de l'adaptateur, redrive après vérification.
3. La dépendance externe n'est pas disponible : pause des retraits, activer la file d'attente delay, redrive après la restauration.
4. Répétez le DLQ après le drave : activez le gestionnaire/simulateur « shadow », vérifiez l'idempotence, réduisez le batch.
5. Débordement de DLQ : évacuation vers l'archive-stockage, activer la redrive sélective pour les clés/raisons.

15) Test et chaos

Injection d'erreurs : schema-break, validation, temporisation, erreurs « collantes » 1-sur-N'.
Massique : contrôle du dosage et de l'effet sur la prode.
Out-of-order de la séquence : le traitement par clé est correct.
Corruption de la charge utile : validation et refus sécurisé.
Récupération après une chute de redrive worker : idempotence des opérations de batch.

16) Erreurs typiques

L'absence de métadonnées dans le DLQ ne permet pas → de regrouper les causes et de les corriger en toute sécurité.
La redrave de masse sans limites → la dégradation répétée de la production.
Il n'y a pas d'idempotence/dedup → de prise et d'effets indésirables.
Mélange de PII dans le DLQ central sans sanitation.
Absence de schémas/contrats → « surprises » dans l'évolution des messages.
Le seul DLQ générique sans lot par tenants/clés.
Retraits infinis au lieu d'un DLQ précoce pour les erreurs non rétractables.

17) Recettes rapides

Flux d'affaires habituel : 3-4 tentatives, backoff exponentiel avec gitter, classification précoce des erreurs, DLQ avec métadonnées complètes.
Événements critiques (paiement) : idempotence stricte, brefs délais, minimum de tentatives, DLQ rapide et analyse manuelle.
Masse redrive après coup : petites batches (100-500), rate-limit, pool de worker séparé, suivi du succès> 95 % avant augmentation de la vitesse.
Multi-tenant : Limites per-tenante pour le redrave, rapport sur les meilleurs clients de générateurs DLQ.

Conclusion

Le DLQ n'est pas une « poubelle », mais un circuit de fiabilité contrôlé. Des règles de pénétration claires, des métadonnées riches, l'idempotence et la déduplication, un système de distribution sécurisé, la discipline des schémas et l'observation transforment les messages toxiques d'une menace pour les SLO en un processus d'ingénierie gérable - avec des pleybooks compréhensibles, des coûts prévisibles et un impact minimal sur les utilisateurs.