A SaaS product can have plenty of healthy servers and one shared reason for every customer to stop working: a bad release, an expensive import or a request that crashes its handler. Adding instances does not necessarily reduce the impact. Sometimes it only distributes the problem more effectively.
Cell-based architecture serves different customer groups through separate cells. This is not the familiar split into payments, catalogues and reporting. A cell contains the components needed to operate a particular service for its assigned workload. The primary division is between groups of work, not feature names.
Choose a boundary that fits how customers work
Consider a maintenance-management platform serving several companies. The organisation may be a useful partition key: its staff, tickets and documents remain together. An overloaded import for one customer is then less likely to exhaust everybody else's capacity, provided the relevant resources are genuinely separated.
Partitioning individual users may be a poorer fit. Colleagues constantly work on shared tickets, so routine operations would cross cell boundaries. If completing an ordinary request requires a synchronous response from a neighbouring cell, that neighbour's failure becomes our problem again.
Test the partition key against collaboration, search, exports and organisational changes. A convenient way to distribute identifiers evenly is not necessarily a good boundary for independent work. AWS's cell architecture overview explains the role of the partition key.
A cell needs a tested capacity limit
If each cell simply grows indefinitely, the company eventually acquires several versions of its original scaling problem. A more useful design establishes the workload a cell can safely handle: the mix of interactive requests, background work and data that meets the agreed service quality.
Customer count is only a rough proxy. A small company and a large chain may have radically different workloads. Placement needs to consider data volume, peak operations and room for growth, not just tenant numbers.
Before the safe boundary is reached, add another cell or move suitable workloads. A large customer may need dedicated capacity, but a dedicated cell still has limits. If that customer's workload exceeds the tested capacity, another meaningful partition or a service redesign is needed.
Bounded cells make it possible to test the size the company actually intends to operate. That is a central benefit in AWS's cell-based scaling guidance, rather than endlessly enlarging every individual unit.
Shared dependencies can undo the boundary
Separate applications using one shared queue or database may still interfere with one another. Isolate the resource that can be exhausted, not only the processes on a deployment diagram. Some risks can be addressed with separate pools and limits; others require independent storage or stronger infrastructure boundaries.
Shared services may remain: routing, identity, configuration and placement management. State explicitly what happens if each fails. Losing the ability to provision a new cell need not stop existing customers, but only if the normal request path is designed to keep operating without that management activity.
Keep routing narrow: find the assigned cell and dispatch the request. Adding pricing, complicated permissions and workflow orchestration there creates another shared failure centre. AWS's routing guidance calls for a thin, predictable layer.
Identical code can fail together too
Resource isolation does not contain a faulty release deployed to every cell simultaneously. The same applies to a global configuration error or feature activation. Roll changes out in stages, observing actual workflows before expanding exposure. Delayed failures also matter: one healthy check immediately after deployment is limited evidence.
At the same time, avoid turning every cell into a unique product. Temporary version differences during rollout are manageable; permanent collections of manual exceptions make recovery unpredictable. Repeatable deployment and configuration tracking become everyday operating requirements.
Cells are not geographic recovery sites either. Several isolated groups inside one region can still lose that region's infrastructure together. Regional resilience protects a different boundary, even when both approaches are used in one product.
You cannot simply send affected customers next door
A healthy cell may have neither the customer's data nor spare capacity. Blind reassignment can spread overload and introduce data-access failures. Limiting how many customers are affected does not automatically recover those already experiencing the incident.
A planned move must coordinate data, unfinished jobs and the moment write ownership changes. Decide how requests are handled during the transition and where repeated old messages will go. Once the new cell accepts changes, sending traffic back to the old one is not a complete rollback.
The move must also preserve access boundaries inside the customer's workspace. Merging departments or changing user membership should not accidentally grant access to another organisation's documents through a technical placement rule.
Evaluate the protection you actually bought
The percentage of affected tenants is not enough. One cell might hold the largest customers or the most critical workflow. Measure consequences for those processes, recovery time and support effort rather than promising that every incident affects an equal small fraction of revenue.
The cost includes spare capacity, operating several groups, migrations and testing shared infrastructure. Existing resources can sometimes be reorganised instead of multiplying every server. Additional procedures and potentially idle reserved capacity still need to be accounted for.
A useful acceptance exercise overloads one selected cell within an approved test and verifies real work in the others. Then test routing failures and a staged release. If neighbouring cells survive only while a particular shared service remains healthy, record that limit instead of declaring the entire platform isolated.