Cell-based architecture divides a service into repeatable, bounded units that each serve a subset of customers or workload. Its value is not the extra boxes on an architecture diagram. It is the promise that a bad deployment, traffic surge, corrupted cache or exhausted quota in one cell does not become a fleet-wide outage. That promise holds only when data, synchronous dependencies, routing and operational change respect the cell boundary. A nominal cell that shares one database or mandatory global service remains part of a global failure domain.
AWS's cell-based architecture guidance treats a cell as a complete independent instance with fixed maximum size and covers routing, sizing, placement, migration, deployment and observability. That breadth is important. Teams that replicate compute but postpone placement and fleet operations usually gain cost and complexity before they gain containment.
Define a cell by failure independence
List the customer operations the cell must continue during isolation. Include request handling, authorization inputs, queues, caches, databases and local service discovery required on the critical path. Shared identity issuance, billing and analytics may remain global if existing sessions and transactions can safely continue when those services are unavailable. Make dependency direction one way where possible: control systems publish versioned intent into cells; serving paths do not synchronously call back for every decision.
Choose the isolation boundary that addresses likely failures. Separate accounts, subscriptions or projects can contain quotas and administrative mistakes; network and identity boundaries can prevent accidental cross-cell access; separate data partitions prevent one storage failure from affecting every tenant. Physical duplication alone is insufficient if one deployment credential, configuration push or schema command can mutate all cells simultaneously.
| Boundary | Containment requirement | Common leak | Verification |
|---|---|---|---|
| Compute | Cell has independent capacity and scaling controls | Shared regional quota exhausts all cells | Load one cell to its cap while peers serve normally |
| Data | Cell owns its tenant partitions and backups | Global primary database | Disconnect or throttle one partition |
| Network | Routes and dependencies can isolate one cell | Mandatory central proxy | Block cell-to-global path during a service test |
| Change | Rollout and rollback can stop per cell | Fleet-wide mutable configuration | Inject a bad canary and prove halt |
| Operations | Identity and telemetry preserve cell context | Shared admin action has unbounded target | Require scoped command and audit record |
Size cells around tested hard limits
A cell needs a declared maximum, not an aspirational average. Model the dimensions that saturate first: active tenants, requests, connections, queue throughput, storage, database transactions, hot keys or third-party calls. Test the largest permitted cell with skewed tenant behavior and degraded dependencies. Keep operating headroom for failover, deployments and recovery. When capacity reaches the placement threshold, add a cell or stop admission rather than silently expanding the boundary until it is unique and untested.
Cell size is an economic and reliability tradeoff. Smaller cells reduce affected population and make full-scale tests affordable, but duplicate fixed resources and increase fleet count. Larger cells improve utilization but enlarge incidents and may encounter nonlinear service limits. Use customer-impact minutes, cell fixed cost, placement flexibility and maximum tested load as decision inputs. Revisit sizing from evidence, not from a desire to make every cell identical forever.
Route tenants without introducing global fragility
Maintain a durable tenant-to-cell assignment. A router may resolve a hostname, token tenant claim or catalog lookup, but the request path must tolerate catalog loss. Cache signed, versioned mappings at multiple edges and define freshness limits. Prevent fallback to a random healthy cell when tenant data is absent there. Health should distinguish cell unavailability from a routing-control outage, and failover should occur only to a prepared destination with data and capacity.
Azure's deployment stamp pattern similarly warns that centralized routing and moving tenants add complexity. Keep resolution deterministic and observable: log tenant, selected cell, mapping version and reason. Test stale mappings, partial propagation and split-brain updates. Protect routing administration because a mistaken bulk remap can defeat every downstream isolation boundary.
Operate many cells as one governed fleet
Standardize a cell contract in infrastructure as code: resource graph, policies, dashboards, alarms, backup plan and synthetic checks. Produce cells from one versioned definition and detect drift continuously. Fleet tooling should enumerate targets but execute in bounded waves with per-cell health gates. Operators need aggregate views for comparison and cell-scoped views for diagnosis. Normalize metrics by workload so a small cell and a busy cell can be compared without hiding saturation.
Use cells as deployment rings. Start with a canary cell containing synthetic or low-risk load, then expand to a small production cohort and subsequent waves. Stop on service-level and tenant-level signals, not only process health. Azure redundancy guidance connects repeatable stamps with isolated failure domains and safe deployment; the operating mechanism is what turns topology into that outcome.
Design tenant movement before it becomes urgent
Migration needs a resumable state machine: validate eligibility, reserve target capacity, establish data copy, catch up changes, verify tenant-scoped integrity, switch routing, observe, and retire the source after a rollback window. Use idempotent steps and one authoritative assignment version. Decide how writes behave during cutover and how background jobs, webhooks, encryption keys and audit history move. A manual database copy is not a migration capability.
| Fleet event | Safe mechanism | Evidence | Unsafe shortcut |
|---|---|---|---|
| New cell | Automated build from approved cell version | Conformance and synthetic test | Clone an old environment manually |
| Release | Bounded waves with cell stop conditions | Version and health by cell | Update all cells in parallel |
| Tenant move | Reserved, resumable copy and atomic route change | Counts, checksums and mapping history | Change DNS after a one-time export |
| Cell evacuation | Capacity-aware prioritized migration | RTO and tenant completion status | Send traffic to any healthy cell |
| Cell retirement | Verify no tenants, jobs, keys or routes remain | Deletion approval and residual scan | Delete compute after traffic falls |
Audit the services that quietly reconnect cells
Classify every shared dependency by outage behavior
A dependency inventory should label each call as cell-local, asynchronous global, cached global or synchronous global. Cell-local services fail with the tenant population they serve. Asynchronous global systems, such as billing export or fleet analytics, can accept delayed delivery. Cached global facts, such as tenant placement, need a last-known-good version and explicit freshness rule. Synchronous global calls require the strongest challenge: if identity lookup, feature evaluation, secrets retrieval or quota authorization is mandatory on every request, that service may define the real fleet blast radius regardless of the application diagram.
Do not ban all shared infrastructure. Instead, specify a degraded behavior and test it. A globally issued signing key may be verified from a cell-local cache. A fleet deployment controller may become unavailable while the current application version keeps serving. Central observability may lose live events while a bounded local buffer protects evidence. Dependencies that cannot degrade should be partitioned, replicated with independent failure modes, or acknowledged as an exception whose business impact is measured.
Run cell game days that include the routing layer
Exercise overload, bad configuration, database exhaustion, a poisoned cache, certificate failure and partial network isolation in one cell. Verify that routing stops new assignments, affected tenants receive a truthful service state, healthy cells retain headroom and automation does not roll the same defect through the fleet. Then restore the cell without moving the incident into another one: reconcile data, warm caches, reopen traffic gradually and confirm that temporary routing decisions expire.
Track containment with concrete measures: percentage of tenants affected, cross-cell error correlation, time to freeze a rollout, time to evacuate or restore a cell, placement headroom and drift from the unit contract. A cell design is improving when incidents remain within their predicted population and operators use the same runbooks across units. If every cell requires bespoke diagnosis, the architecture has exchanged failure coupling for operational fragmentation.
Use the six-stage Edilec cell fleet lifecycle
The lifecycle joins architecture and operations: bound the cell, cap it, place tenants, route locally, change gradually and learn across the fleet. Treat every stage as a testable contract. If a new shared dependency is added or one cell receives a permanent exception, reassess containment and repeatability before calling the design cell-based.
Key takeaways
- A cell is defined by independent service behavior during failure, not by duplicated compute.
- Cap and test cell size across the dimension that saturates first.
- Cache tenant routing safely and never fail a tenant into an unprepared cell.
- Use one versioned cell contract with bounded rollout waves and cell-scoped evidence.
- Build tenant migration as a routine, resumable platform capability.
Frequently asked questions
How many cells should a service start with?
At least enough to exercise routing, fleet deployment and isolation in production-like conditions. One cell permits hidden singleton assumptions; the economically right production count depends on fixed cost, impact tolerance and tested capacity.
Is a cell the same as a region?
No. A region can contain several cells, and a cell normally stays within one region. Regional and cellular boundaries address different infrastructure and application failure scopes; Google deployment archetypes help place the regional layer.
Can cells share services?
Yes when loss or overload of the shared service does not stop the promised serving path, and when its mutation authority cannot damage all cells. Prefer asynchronous projections and bounded degradation for global control functions.
Conclusion
Cells reduce blast radius only when the organization accepts bounded capacity, explicit placement and disciplined fleet change. Design the independent serving path first, then automate routing, migration and evidence across identical units. The result is not fragmented operations; it is one operating model applied to many failure-contained service slices.