Load balancing: the chai stall that got famous
Vertical version.
Chapters
Narration
One stall. One stove. One person making chai. It is perfect, and it is cheap, right up until the cricket match ends and five hundred people want chai in the same minute. There are only two ways out of this. Buy a bigger stove, which works until stoves stop getting bigger, and when that one stove dies everything dies with it. Or open more stalls, which has no ceiling at all. But now nobody knows which stall to walk to. So you put a man at the entrance with a token book. Every customer asks him, and he points them at a stall. He is the only one who needs to know how many stalls there are. He has three ways to decide. Next stall in turn, which is dumb and fair. Shortest line, for when some orders take much longer than others. Or send you back to your usual wala, the one who already knows you. That last one is where it goes wrong. If your running tab lives inside one wala's head, you are chained to him. His line grows, and you wait anyway. He goes home, and your tab goes home with him. So the walas remember nothing at all. Every tab moves to a shared register behind the stalls, and now any wala can serve anyone. The stalls become interchangeable, which is the entire point. Stateless, scale horizontally. That was just a phrase until now. And when a website logs you out right after it updates, you have met a sticky wala who went home mid-shift.
Based on the board The Chai Stall That Got Famous.
Try it in the lab: One wala, many kettles.
Covered in The chai stall that got famous (load balancing), One wala, many kettles (concurrency vs parallelism), The stall, built: copies and shards (replication and sharding in Go).
Saved in this browser only.