Back-of-the-Envelope Estimation

Order-of-magnitude checks catch designs that cannot work. Adjust assumptions for your interview scope — exact numbers matter less than which component becomes the bottleneck.

Assume Wordle-scale daily puzzle: 5M DAU, 1 guess per user per day (6 guesses max), 3M monthly active leaderboard, chess-style async: 500k active games, 10 moves/game/day.

Read/write traffic

• Daily puzzle submit: 5M / 86,400 ≈ 58/s average — tiny; peak (morning ×20) ≈ 1,200/s.
• Each submit: 1 read (puzzle id) + 1 idempotent INSERT ≈ 2,400 DB ops/s peak.
• Chess moves: 500k games × 10 moves / 86,400 ≈ 58 moves/s + validation query.

Storage

• Daily submissions: 5M/day × 365 × 200 B ≈ 365 GB/year.
• Move log: 500k games × 10 moves × 100 B × 365 days ≈ 180 GB/year.
• Board state: 500k active × 2 KB ≈ 1 GB — trivial.

Leaderboard & caching

• Redis ZSET: 3M users × (member + score) ≈ 150 MB per daily board.
• Top-100 query: O(log N + 100) — sub-ms; no SQL ORDER BY on millions of rows.
• Cache puzzle answer hash: 1 key per day — singleflight on submit path.

Network

• Submit payload ~500 B × 1,200/s ≈ 600 KB/s — HTTPS is fine; no UDP needed.
• Push notify opponent: 250k moves/day triggering push ≈ 3/s.

// Daily puzzle peak submits
const dau = 5_000_000;
const avgQps = dau / 86_400;
const peakQps = avgQps * 20; // morning spike
const redisLeaderboardMb = (3_000_000 * 50) / 1e6;
console.log({ peakSubmitQps: Math.round(peakQps), redisLeaderboardMb });