Cell Isolation
Bulkheading at the level of a complete system copy, so that any failure — including ones nobody predicted — is contained to the customers assigned to one cell.
Thread pools isolate a caller from a dependency; cells isolate a set of customers from an entire class of failure. The distinction matters because most bulkheads protect against anticipated failures at a known boundary, whereas a cell contains failures whose mechanism you did not foresee: a poison message, a bad migration, a corrupted cache, an operator error, a code path only one tenant triggers.
For it to hold, isolation must be genuine end to end. A cell that shares a database, a cache, a config service or a queue with other cells is isolated in name only, and finding those shared dependencies is the substantive work of adopting the pattern.
What you gain beyond containment: deployment becomes inherently staged, since releasing cell by cell is the only way to release; capacity is added by adding cells rather than by scaling components; and "drain the cell" becomes a generic mitigation that resolves a broad class of problems without diagnosis.
What you pay: routing becomes a critical shared component, per-cell overhead lowers utilisation, and cross-cell operations need deliberate design.