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.
Caller { # Calling Service
n1: circle label:"Initiate Request"
n2: rectangle label:"Send HTTP Request"
n3: rectangle label:"Receive Response"
n4: circle label:"Request Complete"
n1.handle(right) -> n2.handle(left)
n2.handle(bottom) -> RetryPolicy.n5.handle(top) [label="Execute"]
n3.handle(right) -> n4.handle(left)
}
RetryPolicy { # Retry Policy Engine
n5: rectangle label:"Attempt Request"
n6: diamond label:"Response Status?"
n7: rectangle label:"Return Success"
n8: diamond label:"Retryable Error?"
n9: rectangle label:"Return Permanent Failure"
n10: rectangle label:"Calculate Backoff Delay"
n11: diamond label:"Max Retries Exceeded?"
n12: rectangle label:"Wait with Jitter"
n13: rectangle label:"Return Exhausted Error"
n5.handle(right) -> n6.handle(left)
n6.handle(right) -> n7.handle(left) [label="2xx"]
n6.handle(bottom) -> n8.handle(top) [label="Error"]
n7.handle(top) -> Caller.n3.handle(bottom) [label="Success"]
n8.handle(right) -> n10.handle(left) [label="429/503/Timeout"]
n8.handle(bottom) -> n9.handle(top) [label="400/401/404"]
n9.handle(top) -> Caller.n3.handle(bottom) [label="Non-Retryable"]
n10.handle(right) -> n11.handle(left) [label="2^n * base"]
n11.handle(bottom) -> n13.handle(top) [label="Yes"]
n11.handle(right) -> n12.handle(left) [label="No"]
n12.handle(top) -> n5.handle(bottom) [label="Retry"]
n13.handle(top) -> Caller.n3.handle(bottom) [label="Max Retries"]
}
Target { # Target Service
n14: rectangle label:"Process Request"
n15: diamond label:"Service Healthy?"
n16: rectangle label:"Return 200 OK"
n17: rectangle label:"Return 503 Unavailable"
n14.handle(right) -> n15.handle(left)
n15.handle(right) -> n16.handle(left) [label="Yes"]
n15.handle(bottom) -> n17.handle(top) [label="No"]
n16.handle(top) -> RetryPolicy.n6.handle(bottom) [label="Success"]
n17.handle(top) -> RetryPolicy.n6.handle(bottom) [label="Error"]
n5.handle(bottom) -> Target.n14.handle(top) [label="HTTP"]
}
Transient failures (network blips, temporary overloads) are inevitable in distributed systems. Naive retry strategies with fixed intervals cause thundering herd problems where all clients retry simultaneously. Exponential backoff with jitter spreads retries over time, giving the failing service time to recover.
Fixed-interval retries cause thundering herds. No retries mean transient failures become permanent. Circuit breakers complement retries by stopping attempts to known-failing services. This template shows the complete retry policy engine.
| Template Name | Retry with Exponential Backoff Architecture |
| Category | Architecture |
| Steps | 6 workflow steps |
| Format | FlowZap Code (.fz file) |
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.
Architecture
A circuit breaker resilience architecture diagram showing the complete state machine with closed, open, and half-open states, failure threshold tracking, recovery timer, and fallback response strategies for protecting services from cascading failures. This template visualizes the circuit breaker pattern in detail, including how the breaker transitions between states based on success and failure counts. Essential for building fault-tolerant microservices that degrade gracefully under load.
Architecture
A bulkhead isolation architecture diagram with separate thread pools for critical, standard, and batch workloads, each with independent connection pools, exhaustion detection, and backpressure strategies to prevent one workload from starving others. This template models the bulkhead pattern inspired by ship hull compartments, where resource isolation ensures that a failure or overload in one component cannot cascade to others. Critical for systems requiring guaranteed availability for high-priority operations.
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.