When You Cannot Eliminate Control Plane Calls
Some systems genuinely require Control Plane interactions at runtime. For these systems, the goal shifts from elimination to containment: ensuring that a failure in one part of the system cannot propagate to the whole.
Cellular Architecture
Instead of one monolithic system serving all customers through a single Control Plane, you split the system into independent cells — isolated units that share nothing with each other.
Cell 1: Customers A–M
├── Database (isolated)
├── Queue (isolated)
├── Scaling logic (isolated)
└── Control Plane interactions (isolated)
Cell 2: Customers N–Z
├── Database (isolated)
├── Queue (isolated)
├── Scaling logic (isolated)
└── Control Plane interactions (isolated)
The Poison Pill scenario:
A malformed request enters Cell 1 and triggers a bug that causes the scaling logic to make thousands of rapid RunInstances API calls, exhausting the account's API rate limit.
- Without cellular architecture: The rate limit is shared. Cell 2's scaling logic also starts failing. All customers are affected.
- With cellular architecture: Cell 1 and Cell 2 operate in separate AWS accounts with separate rate limits. Cell 1's runaway API calls cannot affect Cell 2. Only customers A–M are impacted.
AWS uses this internally. When you hear about an us-east-1 outage, it is almost never the entire region. It is typically one or two cells within a single service — a specific set of physical hosts, a specific database shard, or a specific internal API cluster. The cell boundary is what prevents a single bad deployment or hardware failure from taking down all of us-east-1 simultaneously.
The practical implication for your own systems: if you are building a multi-tenant SaaS product, consider whether a single misbehaving tenant can exhaust shared resources (API rate limits, database connections, queue throughput) and affect all other tenants. If yes, you have a blast radius problem that cellular architecture can solve.