One wala, many kettles
Sixteen customers, one wala. If the wala stops standing at each kettle, how much sooner is everyone served?
Every order at the stall is five milliseconds of taking, forty of the kettle brewing, one of pouring. One wala can stand at each kettle, or put it on and take the next order. The timeline shows each order's waiting, working and brewing.
Board: The Chai Stall That Got Famous →On a narrow screen the timeline narrows and the three readouts stack under it.
try this Switch to Juggle the kettles, drag Customers at once and Burners to 64, then watch Walas busy.
The stall, order by order
One row per customer, time running left to right in ms (a millisecond, a thousandth of a second). Each order is 5 ms of taking, 40 ms of brewing and 1 ms of pouring.
All served in
736 ms
from the first customer to the last cup
Orders a second
21.7
served, on average, over the whole run
Walas busy
Each wala stands at a kettle for 40 of every 46 ms, doing nothing. The walas are busy only 13% of the time, and the line still waits.
Sixteen customers, one wala. If the wala stops standing at each kettle, how much sooner is everyone served?
Waiting is not working
Watching each kettle, one wala takes 736 ms for sixteen orders, and is busy for only 96 ms of it. Juggling doesn't make a kettle boil faster. It fills the forty milliseconds of idle time with the next order's work, so the waits overlap instead of queueing end to end. That overlap is concurrency.
Push the customers and the burners to 64 while juggling, and the walas-busy number climbs to 100%. Now every millisecond is spent working, and 64 orders times 6 ms of work is 384 ms however cleverly they are juggled. To go below that floor, you need less work per order or a second wala working at the same time. That isparallelism: more cores.
The burners cap the orders in flight. Without a cap, juggling would put every customer's kettle on at once. In a real system, the thing doing the brewing (usually a database) has a limited number of burners of its own.
Limits of this model
These are teaching values. Five, forty and one milliseconds make the pattern visible: a request that spends most of its time waiting on something else. That is true of most web requests. It is not true of work like resizing an image.
The brew here always takes forty milliseconds, however many kettles are on. A real database slows down as more requests pile onto it, so juggling harder can make every wait longer. This lab models scheduling only.
Every customer arrives at once, and a free wala always picks the task that has waited longest. Real servers take arrivals as they come and schedule in their own ways. A greedy choice like this one can even make an extra burner cost a few milliseconds.