PATTERN Cited by 1 source

AZ sharding for control-plane isolation

Pattern

Shard the control plane's database and service tier along availability-zone boundaries, giving each AZ its own independent control plane instance with a separate database. This simultaneously provides:

1. Blast-radius reduction — a failure in one AZ's control plane cannot propagate to other AZs.
2. Scaling headroom — each shard handles only its zone's subset of resources.
3. Customer-facing building block — the same AZ isolation that protects the control plane is exposed to customers as the primitives for building resilient multi-AZ architectures.

When to apply

• Service is large enough that a single-database control plane is a scaling or blast-radius risk.
• The resource model naturally maps to physical location (e.g., compute instances live in a specific AZ).
• You want independent failure domains without the full complexity of arbitrary cell sharding.

Seen in

• EC2 — "we split each AWS region into multiple availability zones (AZs), each with their own independent control plane and separate MySQL databases. This helped with both scaling and availability, since zones fail independently and the blast radius of any single failure shrinks." The internal follow-up was cell sharding within each AZ. (Source: sources/2026-08-04-allthingsdistributed-on-building-scalable-control-planes)

Trade-offs

• Cross-AZ queries (e.g., "list all my instances in this region") require fan-out across shards.
• Capacity imbalance between AZs requires monitoring and rebalancing.
• Does not protect against correlated regional failures (e.g., DNS, IAM, shared control-plane components).