Section 3: Capacity Says One Region, Physics Says Three - Scale Estimation & Workload Analysis

Executive Summary: Ten million games a day becomes 167K live games and ~28K moves a second at peak, but the totals are small: 167 MB of live state, 186 Mbit/s of pushes, 28K tiny writes a second. Capacity fits in one region. Physics and blast radius don't: a Bengaluru player against a server in Virginia pays ~250 ms per round trip, and one region failing would stop all chess. So the design gets three regional cells and 30 game servers, sized by blast radius rather than CPU. The real peak is the top of the hour, when tournaments start 3,000 games a second, 8.6× the normal creation peak.

The interviewer caps the marker. "Requirements are clear. How big is this, and which numbers matter?" You write the inputs in a corner, because everything later is derived from them:

DAU 10M · games 10M/day · rated 80% → 8M/day
Mix: bullet 30%, blitz 50%, rapid 20% → 7 time-control pools
Average game: 80 plies, 480 s · peak factor 3×

From Games a Day to Moves a Second

Little's law does the heavy lifting: concurrent work equals arrival rate times how long each item stays.

Starts:     10M / 86,400 s        = 116/s avg  → ×3 ≈ 350/s peak (347)
Concurrent: 116/s × 480 s         = 55,680 ≈ 56K avg → ×3 ≈ 167K peak
Players:    167K × 2              = 334K in live games
Moves:      10M × 80 = 800M/day   → ~9,260/s avg → ×3 ≈ 28K/s (27,800)
Pairing:    350 games/s × 2       = 700 seekers paired/s at peak

Interviewer: "28K moves a second sounds high for chess. Sanity-check it."

You: "Two ways in should agree. Each game has one ply every 6 seconds, 480 s over 80 plies. 167K games over 6 s is 27.8K a second, which matches."

Quick check before moving on: