Back-of-envelope estimation

Before a single bar is built, the organiser works from the ticket count and how people behave.

At the festival	In the estimate
40,000 ticket holders × 3 drinks each an evening	users × actions (step 2)
the bars open 18:00–24:00, not all day	the active window (step 3)
the changeover before the headline act, when the queues triple	the peak factor (step 4)
the skips hold the weekend's rubbish; the rush does not make it bigger	peak multiplies rates, not totals (step 6)
nobody counts cups to the unit	round hard (step 10)
a trestle bar, a row of bars, or a separate bar field	one box, ten boxes, a different design (step 11)

In real terms: a rate is a total divided by the seconds it really spans, multiplied by a peak factor; totals such as storage add up every day and ignore the peak.

Breaks down when: one drink is one purchase, but one web request can look up dozens of rows (step 9). The festival has nothing like that fan-out.

Contrasting case: staffing the bars as if all 40,000 people ordered in the same second. That is "everyone at once" (step 5), not a peak.

4.1 ExamHall: the proctor console live feed

EXH-1680: at the first exam start of a busy morning, the alert feed fell minutes behind. Its consumers were sized from the day's alert count spread over 24 hours, with no peak factor. MR !1880 sizes it from the exam-hours window and the busiest minute in last term's logs, and writes every input down with its source.

4.1 heartbeats: 2,400 candidates / 10 s = 240 messages/s, flat through the sitting (one sitting, so no peak factor)
4.1 alerts: 2,400 x 25 = 60,000 rows per sitting, 24 MB; each is read by the proctor's console and the room supervisor's: 2 reads per write
4.1 hook: 50,000 autosaving every 10 s = 5,000 writes/s; 50,000 starts in 10 min = 83.3/s average; half in the first minute = 417/s (5x the average)

ECON-201's feed is small: 240 messages a second is one box (steps 2, 11). The platform-wide start is the rate to watch. Its first minute runs at 5× the ten-minute average (step 4).

4.2 Proof domain, catalog: exact against rough

Two million products with 8 images of 300 KB, kept twice; 30 million searches a day, evening peak 3×; a search box handles 2,000 a second.

4.2 exact images 8.94 TiB · peak search 1,040/s -> 1 search box(es) at 2,000/s
4.2 rough images 10 TB  · peak search   900/s -> 1 search box(es) at 2,000/s
4.2 search responses at peak: 41.7 MB/s = 333 Mbit/s

Binary units and a 10^5-second day move each number by 10–15%. Neither moves the decision: about 10 TB of images and one search box (step 10). At 40 KB per result page, the peak's 41.7 MB/s is 333 Mbit/s on the wire (step 8).

4.3 The original: Jeff Dean's thumbnail page (LADIS 2009)

Dean's slide asks how long a results page of 30 thumbnails takes. The inputs are his cited figures: a disk seek of 10 ms, and reads at 30 MB/s.

4.3 serial: 30 x 10 ms + 30 x 256K / 30 MB/s = 556 ms (slide: 560 ms)
4.3 parallel: 10 ms + 256K / 30 MB/s = 18.5 ms (slide: 18 ms)

A 30× gap, found before anything was built, picks the design (step 1). The latency figures are inputs from the slide, not something to recall.