The slate next to the stove
The slate is full and someone asks for something new. Which line gets erased?
A chai stall keeps its prices on a small slate next to the stove, and ten customers ask for things in a fixed order. The three panels show the queue, what is chalked now, and how often someone walked to the back for an answer. Switching the rule changes which line survives.
Board: The Slate Next to the Stove →Ten fixed questions, one slate. Step through them by hand.
try this Pick Longest unasked, press Add next question until all ten are asked, then drag Lines the slate holds and watch The register.
The queue
- 1chaiwalk
- 2chai
- 3chai
- 4vada
- 5tab
- 6vada
- 7lassi
- 8chai
- 9tab
- 10lassi
The slate
3 lines, chalked as they're asked.
- chai
The register
1
walk to the back so far
Now: chai
1 of 10 askedThe slate is full and someone asks for something new. Which line gets erased?
Why longest unasked matters
Longest unasked tracks when each line was last read and erases the one read longest ago. A line nobody has asked for recently is usually not about to be asked for. In this run it erases chai after a few orders without a request. The very next order asks for chai, so the slate needs an extra walk to the back.
The tradeoff: Tracks recency well; a rare line having one busy morning can look permanently popular.
The two curses
Curse one: staleness. "Milk price rose in the register; the slate still says ₹10." A line can look right and be wrong, and the customer gets a confident, wrong answer. This lab touches on it only briefly. Switch the policy above to Expiry and watch a line go blank on a timer, whether or not the answer underneath changed.
Curse two: the slate is small. When it's full, something has to go. This is the curse the lab models: five rules for choosing, and a hit rate that changes with the one you pick.
Limits of this model
One slate, whole-line keys and ten fixed questions. A real system layers several caches: browser → CDN → app → database, each one faster, smaller and staler than the one behind it.
The hit rate here is arithmetic on a fixed list. A real cache's hit rate depends on a live, shifting access pattern. This one repeats the same ten orders every run so the five policies can be compared fairly.
Every key here is a whole answer ("chai", "₹10"). A real cache often stores partial objects, ranges or computed fragments, and invalidating a fragment is harder than erasing a line.
Sources
see also Consistent Hashing and Random Trees, Kafka: a Distributed Messaging System for Log Processing, Zanzibar: Google's Consistent, Global Authorization System and Scaling Memcache at Facebook in Papers.