A cell-based SaaS architecture divides the tenant fleet across repeatable, bounded deployments. Each cell, also called a deployment stamp or scale unit, contains the application and data resources needed to serve a subset of tenants. New cells add capacity and reduce the number of customers affected by a local failure. The model sits between one shared stack with a large blast radius and one bespoke stack per customer with poor cost and operating leverage.
Cells are not automatically isolated or inexpensive. Shared identity, routing, deployment, observability, and control-plane dependencies can still fail across every cell. Too-small cells strand capacity and multiply upgrades; too-large cells recreate the original risk. Microsoft defines stamps as independently deployed groups that can serve a predefined tenant set and scale nearly linearly. The product decision is how to define that unit, size it from evidence, place tenants, operate the fleet, and move tenants when assumptions change.
Choose the failures and limits a cell must contain
Write a containment objective. Decide whether a cell bounds application defects, database saturation, queue backlog, cache corruption, accidental deployment, data-plane credentials, region failure, or tenant data access. Identify dependencies intentionally shared across cells and the consequence of their failure. A shared global router can make every cell unreachable; a shared write database means data failure is not cell-local. Keep a dependency map and label each component cell-local, regional shared, or global shared.
Define the customer impact target in tenant count, revenue class, data scope, recovery time, and communication burden. Fault domains should align with deploy and rollback domains where practical. If one application release goes to all cells simultaneously, cells will not contain a software defect. If all cell credentials share one administrative secret, they will not contain compromise. The architecture needs progressive delivery, separate runtime authority, and per-cell health decisions to make the boundary operationally real.
| Boundary choice | Isolation benefit | Cost or complexity | Decision evidence |
|---|---|---|---|
| Compute per cell | Bounds saturation and many runtime defects | Base capacity and fleet management | Peak CPU, memory, queue, and failover |
| Database per cell | Bounds data load and restore scope | More instances, migrations, analytics fan-in | Size, IOPS, restore, connection limits |
| Queue per cell | Bounds poison work and backlog | More topics, policies, monitoring | Throughput and recovery behavior |
| Region-specific cells | Residency and regional fault boundary | Routing and regional operations | Demand, regulation, service availability |
| Shared control plane | Unified placement and operations | Potential global dependency | Cached data-plane behavior during outage |
Define one reproducible cell template
Specify compute, data stores, queues, caches, keys, network policy, service identities, quotas, backup, observability, deployment hooks, and acceptance tests as versioned infrastructure and configuration. Avoid pet cells with hand-applied fixes. Variations should be a small set of declared classes, such as standard, high-memory, or regulated-region, with compatibility and cost understood. Give each cell an immutable ID, region, class, template version, capacity state, software ring, and lifecycle status in the tenant catalog.
Create a cell through automation, seed no customer data, run functional and isolation tests, load test a canary population, register routing, and only then mark it available for placement. Destruction should prove tenants are absent, retention and backup obligations are satisfied, routes and credentials are removed, and evidence is retained. Continuously detect drift between template and deployed state. Rebuildability is a stronger property than a long runbook of manual repairs.
Size cells from workload distributions and recovery
Use per-tenant distributions for requests, concurrent sessions, storage, database work, background jobs, events, exports, and growth. Average tenant load is dangerous for bin packing because a few heavy tenants can dominate. Model correlated peaks such as month end, campaign sends, or regional business hours. Include headroom for failover, deploy surge, queue recovery, maintenance, and organic growth. Define hard and soft limits plus admission thresholds before a cell reaches unsafe saturation.
There is no universal tenants-per-cell target. Choose a maximum based on capacity, failure impact, restore time, and economics, then validate with production-shaped load and fault tests. A cell that runs at 80 percent during normal peak may have no room to drain backlog after a dependency outage. Conversely, a cell held mostly empty can erase margin. Review unit economics as fixed per-cell cost, variable workload cost, shared platform allocation, operations burden, and reserved recovery capacity.
Place tenants with policy and measurable capacity
The control plane should filter eligible cells by residency, compliance class, product version, contractual isolation, region, and feature requirements, then score available capacity and risk. Include tenant affinity or anti-affinity where organizations should stay together or high-risk tenants should be separated. Avoid revealing cell IDs as permanent customer-facing endpoints. Route through a tenant-to-cell map with versioning, controlled cache, and safe behavior during placement updates.
Placement needs admission control. Reserve capacity before onboarding, provision tenant state idempotently, run acceptance, activate routing, and release the reservation on failure. Do not place based on tenant count alone. Record why the choice was made and the capacity snapshot used. Continually compare predicted and observed load. A large tenant may need a dedicated cell, but that should use the same template and fleet tooling rather than becoming a custom environment.
| Fleet metric | Why it matters | Trigger example | Action |
|---|---|---|---|
| Cell peak saturation | Signals admission and stability risk | Soft threshold sustained | Stop placement and plan capacity |
| Largest tenant share | Reveals local noisy-neighbor exposure | Single tenant dominates constrained resource | Throttle, optimize, or relocate |
| Recovery headroom | Determines backlog and failover ability | Below declared reserve | Reduce load or add cell |
| Template drift | Undermines repeatability and security | Unapproved resource difference | Reconcile or rebuild |
| Cost per active tenant | Tests operating leverage | Rises outside segment model | Adjust size, density, or tier price |
Operate releases and incidents as a fleet
Deploy through rings: test, internal, canary cell, small production set, then wider waves. Evaluate technical health, business transactions, and tenant support signals before promotion. Stop automatically on declared regressions. Keep schema and message changes backward compatible across adjacent versions because cells will differ during rollout. Report cell-local and fleet-wide metrics. An aggregate can hide one unhealthy cell, while a page per cell can overwhelm operators; use fleet views with drill-down and consistent dimensions.
Runbooks should support isolating ingress, pausing placement, draining work, restoring a cell, and communicating only to affected tenants. Global shared dependencies need separate resilience plans and fault injection. Maintain a cell health score for routing and placement, but do not move stateful tenants automatically based on one noisy metric. Movement is a controlled data migration with authority, consistency, and rollback, not load-balancer behavior.
Design tenant movement before it becomes urgent
A relocation workflow should provision target state, establish data replication or export/import, copy configuration and keys safely, verify counts and semantics, quiesce or capture changes, switch the catalog and routing atomically, monitor, and retire source state after a rollback window. Decide acceptable write downtime and whether dual writes are justified. Preserve tenant identity and customer URLs while placement changes. Test migrations across software and schema versions allowed by the fleet.
Use movement for planned rebalancing, regional change, dedicated-tier promotion, cell retirement, and disaster recovery. Rehearse evacuation at realistic data size and measure copy rate, validation, routing propagation, cache expiry, and rollback. A recovery plan that assumes every affected tenant can move simultaneously may exceed network, database, and operator capacity. Prioritize by consequence and reserve transfer capacity. Update cost and containment assumptions with each exercise.
Cross-cell analytics and administrative search need an explicit architecture. Prefer governed event or analytical pipelines over live fan-out queries to every operational database. Publish cell ID, tenant identity, source cutoff, schema version, and completeness so consumers can reason about freshness. Fleet jobs should rate-limit per cell and tolerate one unavailable cell without reporting a complete global result. This keeps reporting from becoming an unplanned shared dependency that erodes cell isolation.
Key takeaways
- Define exactly which runtime, data, deployment, and credential failures the cell contains, including shared dependencies that remain global.
- Build cells from a small set of versioned templates with automated creation, acceptance, drift detection, and retirement.
- Size from tenant workload distributions, correlated peaks, recovery headroom, restore objectives, and unit economics rather than tenant averages.
- Use a control-plane placement policy with eligibility, capacity reservation, admission control, and reasoned tenant-to-cell mapping.
- Operate releases as progressive fleet changes and test stateful tenant relocation and cell evacuation before emergencies.
Frequently asked questions
Do cells require microservices?
No. A cell can contain a modular monolith, services, serverless functions, or a mix. The important properties are repeatable deployment, bounded tenancy, explicit dependencies, independent health, and operable fleet lifecycle.
Is one tenant per cell the safest design?
It offers strong local isolation but adds fixed cost, fleet size, and management overhead. Use dedicated cells for justified requirements while pooled cells preserve efficiency for tenants whose risk and workload fit shared capacity.
Can routing alone move a tenant between cells?
Not when state is cell-local. Data, configuration, jobs, files, caches, keys, and integrations need a controlled migration and reconciliation. Routing changes only after target state is ready and rollback is defined.
Conclusion
Cell-based SaaS creates a useful middle architecture when the unit is explicit and repeatable. Capacity evidence prevents arbitrary sizing, placement policy prevents accidental hot spots, progressive delivery makes containment real, and migration preserves flexibility. With those controls, cells reduce outage scope and support growth without turning every tenant into a separately engineered product.