Architecture
Diagramme d'architecture de file de lettres mortes avec politiques de retry, backoff exponentiel, seuils de tentatives maximales, routage DLQ pour les messages échoués, alertes opérationnelles et workflows de retraitement manuel. Ce modèle représente le pattern critique de gestion des erreurs pour les systèmes de messagerie asynchrone, garantissant qu'aucun message n'est silencieusement perdu lors d'un échec de traitement. Essentiel pour construire des systèmes événementiels fiables avec des mécanismes de récupération appropriés.
Code FlowZap complet
Producer { # Message Producer
n1: circle label:"Publish Message"
n2: rectangle label:"Serialize Payload"
n3: rectangle label:"Send to Main Queue"
n1.handle(right) -> n2.handle(left)
n2.handle(right) -> n3.handle(left) [label="Enqueue"]
n3.handle(bottom) -> MainQueue.n4.handle(top) [label="Deliver"]
}
MainQueue { # Main Processing Queue
n4: rectangle label:"Receive Message"
n5: rectangle label:"Attempt Processing"
n6: diamond label:"Processing Succeeded?"
n7: rectangle label:"Acknowledge Message"
n8: rectangle label:"Increment Retry Count"
n9: diamond label:"Max Retries Exceeded?"
n4.handle(right) -> n5.handle(left)
n5.handle(right) -> n6.handle(left)
n6.handle(right) -> n7.handle(left) [label="Yes"]
n6.handle(bottom) -> n8.handle(top) [label="No"]
n8.handle(right) -> n9.handle(left)
n9.handle(top) -> n5.handle(bottom) [label="Retry"]
n9.handle(bottom) -> DLQ.n10.handle(top) [label="Exceeded"]
}
DLQ { # Dead Letter Queue
n10: rectangle label:"Route to DLQ"
n11: rectangle label:"Store Failed Message"
n12: rectangle label:"Alert Operations Team"
n13: rectangle label:"Manual Review Dashboard"
n14: diamond label:"Reprocessable?"
n15: rectangle label:"Requeue to Main"
n16: rectangle label:"Archive and Close"
n10.handle(right) -> n11.handle(left) [label="Preserve Context"]
n11.handle(right) -> n12.handle(left) [label="PagerDuty"]
n12.handle(right) -> n13.handle(left)
n13.handle(right) -> n14.handle(left) [label="Investigate"]
n14.handle(right) -> n15.handle(left) [label="Yes"]
n14.handle(bottom) -> n16.handle(top) [label="No"]
n15.handle(top) -> MainQueue.n4.handle(bottom) [label="Replay"]
}
Pourquoi ce workflow ?
Without proper error handling, failed messages in event-driven systems are silently lost or cause infinite retry loops that waste resources. A dead letter queue captures messages that exceed retry thresholds, preserving them for investigation and manual reprocessing while keeping the main processing pipeline healthy.
Comment ça fonctionne
- Step 1: A message is received from the main queue and processing is attempted.
- Step 2: If processing fails, the retry count is incremented and the message is requeued.
- Step 3: Exponential backoff delays prevent overwhelming the failing service.
- Step 4: After exceeding the maximum retry threshold, the message is routed to the DLQ.
- Step 5: Operations teams are alerted via PagerDuty and can investigate through a dashboard.
- Step 6: Reprocessable messages are requeued to the main queue after the root cause is fixed.
Alternatives
Ignoring failed messages leads to data loss. Infinite retries waste resources and mask bugs. Logging failures without a DLQ makes recovery difficult. This template shows the complete failure handling lifecycle.
Key Facts
| Template Name | Architecture de file de lettres mortes événementielle |
| Category | Architecture |
| Steps | 6 workflow steps |
| Format | FlowZap Code (.fz file) |
Modèles associés
Architecture
Diagramme d'architecture événementielle publish-subscribe avec broker de messages Kafka ou RabbitMQ, sérialisation d'événements, partitionnement de topics, livraison fan-out vers plusieurs consommateurs et gestion des erreurs via file de lettres mortes. Ce modèle représente le pattern fondamental de messagerie asynchrone où producteurs et consommateurs sont entièrement découplés via un broker de messages. Essentiel pour les architectes construisant des systèmes événementiels faiblement couplés et évolutifs.
Architecture
Diagramme d'architecture de retry avec backoff exponentiel montrant le moteur complet de politique de retry avec classification des erreurs retryables vs non-retryables, calcul de délai exponentiel avec jitter, seuils de tentatives maximales et gestion gracieuse de l'épuisement. Ce modèle représente le pattern de résilience essentiel pour gérer les défaillances transitoires dans les systèmes distribués, prévenant les problèmes de thundering herd par des délais de backoff aléatoires. Fondamental pour toute communication inter-services dans les architectures cloud.
Architecture
Diagramme d'architecture de passerelle API pour microservices montrant le routage des requêtes, l'authentification JWT, la limitation de débit, la découverte de services et l'agrégation des réponses à travers des services backend distribués. Ce modèle représente le point d'entrée de tout le trafic client dans un écosystème de microservices, appliquant les politiques de sécurité avant que les requêtes n'atteignent les services internes. Idéal pour les ingénieurs plateforme concevant une infrastructure API évolutive avec des préoccupations transversales centralisées.
Architecture
Diagramme d'architecture de maillage de services avec proxys sidecar Istio ou Linkerd gérant le chiffrement mTLS, les politiques de trafic, le disjoncteur et le traçage distribué à travers les microservices. Ce modèle visualise comment un maillage de services abstrait les préoccupations réseau du code applicatif, permettant une communication zero-trust entre les services. Essentiel pour les équipes adoptant une infrastructure de maillage de services pour améliorer l'observabilité et la sécurité.
Architecture
Diagramme d'architecture base de données par service où chaque microservice possède son propre magasin de données dédié, avec synchronisation événementielle via Kafka pour la cohérence des données inter-services. Ce modèle démontre le principe fondamental d'isolation des données des microservices, montrant comment PostgreSQL et MongoDB coexistent dans une stratégie de persistance polyglotte. Critique pour les architectes imposant l'autonomie des services tout en maintenant la cohérence à terme.
Architecture
Diagramme d'architecture de décomposition de microservices organisé par capacités métier : Identité, Catalogue produits, Tarification et Exécution des commandes, chacun avec des magasins de données et des API indépendants. Ce modèle montre comment découper un monolithe en services alignés sur les domaines métier, en utilisant un pattern Backend-for-Frontend (BFF) pour l'agrégation spécifique au client. Utile pour les architectes planifiant les frontières de microservices orientées domaine.