Tiffin now runs a cell per region: Mumbai for Indian cities, one for the Middle East, one for Singapore. A bad night in Singapore doesn't touch Mumbai. But the Mumbai cell serves every Indian city, about 90% of all orders, and inside it everything is shared: one fleet of order servers, one Kafka cluster, one database cluster. So the question this lesson answers is: when something goes wrong inside Mumbai, how much of India goes down with it?
The honest answer today is "all of it", and redundancy doesn't help. This lesson covers the tools that do: cells inside a region, shuffle sharding, and isolating tenants from each other.
What redundancy doesn't protect against
Redundancy, from earlier in this module, protects against a machine or a zone dying. Spare capacity takes over. But many outages aren't a machine dying. They hit every copy at once, because every copy runs the same code, takes the same traffic and shares the same dependencies:
- A bad deploy or config change. It rolls out to all 200 order servers. All 200 are now broken.
- A poison request. One restaurant's menu has a malformed item that crashes the parser. The load balancer retries it on the next server, which also crashes, and so on through the fleet.
- A noisy neighbour. One big restaurant chain runs a bulk menu import at 7pm, saturating the shared database. Every restaurant's orders slow down.
- A shared dependency failing. The one Redis cluster everyone uses hits its memory limit.
The size of what breaks is the blast radius. Redundancy shrinks the chance of an outage from hardware. Reducing blast radius shrinks how much of the business each outage reaches.