Architecture
A dead letter queue architecture diagram with retry policies, exponential backoff, max retry thresholds, DLQ routing for failed messages, operations alerting, and manual reprocessing workflows. This template models the critical error handling pattern for asynchronous messaging systems, ensuring no message is silently lost when processing fails. Essential for building reliable event-driven systems with proper failure recovery mechanisms.
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"]
}
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.
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.
| Template Name | Event-Driven Dead Letter Queue Architecture |
| Category | Architecture |
| Steps | 6 workflow steps |
| Format | FlowZap Code (.fz file) |
Architecture
An event-driven publish-subscribe architecture diagram with Kafka or RabbitMQ message broker, event serialization, topic partitioning, fan-out delivery to multiple consumers, and dead letter queue error handling. This template models the foundational async messaging pattern where producers and consumers are fully decoupled through a message broker. Essential for architects building loosely coupled, scalable event-driven systems.
Architecture
A retry with exponential backoff architecture diagram showing the complete retry policy engine with retryable vs non-retryable error classification, exponential delay calculation with jitter, max retry thresholds, and graceful exhaustion handling. This template models the essential resilience pattern for handling transient failures in distributed systems, preventing thundering herd problems through randomized backoff delays. Foundational for any service-to-service communication in cloud architectures.
Architecture
A microservices API gateway architecture diagram showing request routing, JWT authentication, rate limiting, service discovery, and response aggregation across distributed backend services. This template models the entry point for all client traffic in a microservices ecosystem, enforcing security policies before requests reach internal services. Ideal for platform engineers designing scalable API infrastructure with centralized cross-cutting concerns.
Architecture
A service mesh architecture diagram with Istio or Linkerd sidecar proxies handling mTLS encryption, traffic policies, circuit breaking, and distributed tracing across microservices. This template visualizes how a service mesh abstracts networking concerns away from application code, enabling zero-trust communication between services. Essential for teams adopting service mesh infrastructure to improve observability and security.
Architecture
A database-per-service architecture diagram where each microservice owns its dedicated data store, with event-driven synchronization via Kafka for cross-service data consistency. This template demonstrates the core microservices data isolation principle, showing how PostgreSQL and MongoDB coexist in a polyglot persistence strategy. Critical for architects enforcing service autonomy while maintaining eventual consistency.
Architecture
A microservices decomposition architecture diagram organized by business capabilities: Identity, Product Catalog, Pricing, and Order Fulfillment, each with independent data stores and APIs. This template shows how to break a monolith into services aligned with business domains, using a Backend-for-Frontend (BFF) pattern for client-specific aggregation. Useful for architects planning domain-driven microservice boundaries.