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.
Full FlowZap Code
Gateway { # API Gateway
n1: circle label:"Incoming Request"
n2: rectangle label:"Classify Request Type"
n3: diamond label:"Request Category?"
n4: rectangle label:"Route to Critical Pool"
n5: rectangle label:"Route to Standard Pool"
n6: rectangle label:"Route to Batch Pool"
n1.handle(right) -> n2.handle(left)
n2.handle(right) -> n3.handle(left)
n3.handle(right) -> n4.handle(left) [label="Critical"]
n3.handle(bottom) -> n5.handle(top) [label="Standard"]
n3.handle(left) -> n6.handle(right) [label="Batch"]
n4.handle(bottom) -> CriticalPool.n7.handle(top) [label="Priority"]
n5.handle(bottom) -> StandardPool.n11.handle(top) [label="Normal"]
n6.handle(bottom) -> BatchPool.n15.handle(top) [label="Low Priority"]
}
CriticalPool { # Critical Thread Pool (10 threads)
n7: rectangle label:"Dedicated Connection Pool"
n8: rectangle label:"Process Payment Request"
n9: diamond label:"Pool Exhausted?"
n10: rectangle label:"Queue with Timeout"
n7.handle(right) -> n8.handle(left) [label="Thread Available"]
n7.handle(bottom) -> n9.handle(top) [label="Check"]
n9.handle(right) -> n10.handle(left) [label="Yes"]
n9.handle(top) -> n8.handle(bottom) [label="No"]
}
StandardPool { # Standard Thread Pool (20 threads)
n11: rectangle label:"Shared Connection Pool"
n12: rectangle label:"Process API Request"
n13: diamond label:"Pool Exhausted?"
n14: rectangle label:"Return 503 Service Unavailable"
n11.handle(right) -> n12.handle(left) [label="Thread Available"]
n11.handle(bottom) -> n13.handle(top) [label="Check"]
n13.handle(right) -> n14.handle(left) [label="Yes"]
n13.handle(top) -> n12.handle(bottom) [label="No"]
}
BatchPool { # Batch Thread Pool (5 threads)
n15: rectangle label:"Rate-Limited Pool"
n16: rectangle label:"Process Batch Job"
n17: diamond label:"Pool Exhausted?"
n18: rectangle label:"Backpressure: Delay Retry"
n15.handle(right) -> n16.handle(left) [label="Thread Available"]
n15.handle(bottom) -> n17.handle(top) [label="Check"]
n17.handle(right) -> n18.handle(left) [label="Yes"]
n17.handle(top) -> n16.handle(bottom) [label="No"]
}
Why This Workflow?
A single slow or failing dependency can consume all available threads or connections, starving healthy operations. The bulkhead pattern isolates workloads into separate resource pools—like watertight compartments in a ship—so that a failure in one pool cannot affect the availability of others.
How It Works
- Step 1: Incoming requests are classified by type: critical, standard, or batch.
- Step 2: Each category is routed to a dedicated thread pool with fixed capacity.
- Step 3: The critical pool (payments) has guaranteed resources that cannot be consumed by other workloads.
- Step 4: The standard pool handles regular API requests with a larger thread allocation.
- Step 5: The batch pool processes background jobs with rate limiting and lower priority.
- Step 6: When a pool is exhausted, requests are either queued with timeout or rejected with 503.
Alternatives
A single shared thread pool is simpler but vulnerable to noisy-neighbor problems. Kubernetes resource limits provide pod-level isolation. This template shows application-level bulkhead isolation for fine-grained workload protection.
Key Facts
| Template Name | Bulkhead Isolation Architecture |
| Category | Architecture |
| Steps | 6 workflow steps |
| Format | FlowZap Code (.fz file) |
Related templates
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 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 cell-based architecture diagram with geographic routing to independent, self-contained cells (US-East, EU-West), each with its own gateway, compute, database, cache, and message queue, plus shared services for cross-cell replication and global configuration. This template models the cell architecture pattern used by hyperscale systems to achieve blast radius isolation, where failures in one cell cannot affect users in another. Key for architects designing systems that require extreme availability and fault isolation.
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.