How do you estimate QPS in a back-of-envelope calculation?
Back-of-envelope QPS estimation follows a top-down decomposition:
**Step 1: Establish user volume** Start with total users, derive DAU. For a social app with 300M users, assume 50% DAU = 150M daily active users.
**Step 2: Estimate requests per user per day** Be specific about the action. A Twitter-like feed has: 3 timeline refreshes/day (reads) + 0.1 tweets/day (writes). That gives 150M × 3 = 450M read requests/day and 150M × 0.1 = 15M write requests/day.
**Step 3: Convert to per-second** 86,400 seconds in a day. Round to 10^5 for easier math. 450M / 100K ≈ 4,500 read QPS average 15M / 100K ≈ 150 write QPS average
**Step 4: Apply peak multiplier** Average QPS understates real load. Traffic peaks — typically 2–3× average for consumer apps, up to 10× for events (sports, flash sales). Use 3× as a default: peak read QPS ≈ 13,500, peak write QPS ≈ 450.
**Step 5: State the read/write ratio** In this case 30:1. This matters for architecture: read-heavy systems use read replicas and caches; write-heavy systems need write sharding or queue-based buffering.
**Key numbers to know:** - 86,400 ≈ 10^5 seconds/day - 1M requests/day ≈ 12 QPS - 1B requests/day ≈ 12,000 QPS
**What interviewers look for**: not the exact number, but structured decomposition, stated assumptions, and knowing whether the answer implies a single server (< 1K QPS), a small cluster (1–10K QPS), or distributed infrastructure (> 100K QPS).
Walks through DAU → requests/day → QPS with correct 86,400 divisor and applies a peak multiplier.
Separately estimates read and write QPS, states the ratio, connects the numbers to architectural implications, and handles assumptions explicitly.
Reading the answer is step one. Explaining it unprompted — under interview pressure — is what actually matters. Get AI-graded feedback on your answer with follow-up probes on your weak points.
Get Graded — Free Assessment