Section 3: The Bottleneck Wears an Apron - Scale Estimation & Workload Analysis

Executive Summary: This section runs the capacity napkin for the salad system and discovers that every number a database engineer would worry about is laughably small — 3.5 orders per second chain-wide, 220 GB a year — while the one number that actually breaks at noon isn't in the computer at all. Lunch demand at a single location runs 2.8× the kitchen's physical throughput, which makes honest queue math, not horizontal scaling, the system's hardest job. You'll practice the estimation pipeline, the discipline of letting small numbers veto big machinery (D5, D6), and the Staff-level move of naming the bottleneck the servers can't see.

The interviewer leans back. "Okay — before you design anything, how big is this? Give me the numbers." Most candidates hear that question as an invitation to justify infrastructure. This system punishes that reflex twice: first because the digital load is tiny, and second because the real scaling problem is standing at a prep counter holding tongs.

One Location: The Numbers the Kitchen Feels

Start where the business starts — one busy downtown location, Via Verde Salads:

Orders:        ~600 orders/day
Salads/order:  × 1.4
Salads made:   600 × 1.4 = 840 salads/day

Spread over a day, that's nothing. But restaurants don't get traffic spread over a day; they get lunch. The 12:00–13:00 hour carries about 40% of daily volume:

Lunch hour:  600 × 0.40 = 240 orders/hour ≈ one order every 15 seconds
Demanded:    240 × 1.4  ≈ 336 salads/hour

An order every 15 seconds would barely register on a server's CPU graph. Now compute what the kitchen can do:

Capacity:  3 assembly stations × 1 salad per 90 s
         = 3 × 40 = 120 salads/hour

Demand vs capacity:  336 ÷ 120 ≈ 2.8× over capacity

Result: The only scaling problem in the building is made of lettuce and labor. The database will idle through the rush while the queue of unmade salads grows by roughly 216 an hour. Say this sentence to the interviewer, because it reframes the entire design: "Peak demand is 2.8 times kitchen throughput — so the system's hardest job isn't handling load, it's telling the truth about a queue it cannot drain."

That truth has arithmetic. When Maya orders at 12:10 and the queue is already 40 salads deep:

Honest wait:  40 salads ÷ 120 salads/hour = 1/3 hour = 20 minutes

The comfortable lie — "ready in 15 minutes!" hard-coded into the confirmation screen — is cheaper to build and catastrophically expensive to run: at 2.8× over capacity the backlog grows by 216 salads an hour, so by 12:40 the queue is ~148 deep and you're quoting 15 minutes on a 70-minute reality. Quoted pickup must be computed from queue depth and station throughput, and past a cap the app must offer the next slot rather than accept an order it can't honor (D10, fully built in Section 8). The napkin just decided a product behavior — that's what napkins are for.

Quick check before moving on: