34 - The Bulkhead Pattern (Isolate your components to prevent failures)
The Bulkhead pattern takes its name from the watertight compartments in a ship’s hull. Just as poorly designed bulkheads contributed to the sinking of the Titanic, poorly isolated cloud services can cause a single failure to cascade across your entire application.
What You’ll Learn
- The Bulkhead pattern as a resilience mechanism for microservices and distributed cloud architectures
- How resource exhaustion in one service can starve others sharing the same underlying infrastructure (e.g., multiple App Services on a shared App Service Plan)
- Partitioning strategies:
- Using connection pools to isolate workloads from specific backend services
- Deploying services onto separate VMs, containers, or App Service Plans to enforce hardware-level isolation
- Using Kubernetes resource requests and limits to guarantee quality-of-service between pods
- How the Bulkhead pattern limits the blast radius of failures, preventing cascading outages in microservices architectures
- Multi-tenancy considerations: per-tenant isolation vs. shared deployment stamps, and the pricing model implications (e.g., Azure SQL Elastic Pools vs. single databases)
- Monitoring individual partitions to ensure per-service SLA compliance, not just aggregate system health
Complementary Patterns
The Bulkhead pattern works alongside the Retry, Circuit Breaker, and Throttling patterns to build comprehensive resilience. Define your blast radius with bulkheads, then layer in these patterns to handle the failures that do occur gracefully.
Related Content
29 - The Sidecar and Ambassador Patterns
When modernising a legacy application, rewriting everything from scratch is rarely feasible. The Sidecar and Ambassador cloud design patterns offer a pragmatic alternative — attach a companion process to offload cross-cutting concerns like retry logic, circuit breaking, and protocol translation without modifying the application itself. Chris and Peter explore both patterns in depth, covering when to use each, how they relate to service meshes, and their role in Kubernetes-based architectures.
27 - The Compute Resource Consolidation Pattern (Optimise for Cost!)
Are you running dedicated compute for every tenant, microservice, or application instance — and paying for it? The Compute Resource Consolidation pattern shows you how to consolidate tasks onto shared infrastructure, such as a single AKS cluster with namespace isolation or an Azure SQL elastic pool, to reduce costs and management overhead. This episode explores the key trade-offs: blast radius containment, noisy neighbour contention, scalability profiles, and multi-tenancy strategies. Part of the "Architecting for the Cloud, One Pattern at a Time" series.
24 - Health Endpoint Monitoring Pattern (Monitor your service and its dependencies!)
Stop waiting for users to tell you something is broken. The Health Endpoint Monitoring pattern gives your services a dedicated health-check endpoint that aggregates the status of all dependent components—databases, APIs, storage—into a single observable response. This episode covers the pattern in detail, including design considerations around caching, security, denial-of-service exposure, and integration with Azure Monitor and Application Insights.