QPS Estimation

QPS estimation computes the request rate a system must handle, derived from user counts and behavior. The base formula:

QPS = (DAU × actions_per_user_per_day) / 86400

where 86,400 is the number of seconds in a day. The result is the average QPS — what the system handles in steady state.

Example: 200M DAU, 50 reads/user/day.

• Reads/day = 200M × 50 = 10B reads/day.
• Average QPS = 10B / 86400 ≈ 115,000 QPS (115k QPS).

This is the starting point. Two refinements make it useful:

1. Peak QPS. Real traffic is never uniform; it has peaks. Peak is typically 3-5x average for normal workloads, 10-100x for event-driven spikes (Super Bowl, breaking news). Design for peak, not average. So 115k average QPS → design for 500k peak QPS.

2. Read QPS vs write QPS. Most systems have very different read and write rates — typically 10:1 to 100:1. The read:write ratio drives the entire caching strategy: read-heavy systems are cache-friendly; write-heavy systems need different patterns. Split QPS into reads and writes before making any architecture decision.

The read:write ratio drives architecture.

Splitting QPS into read and write is the most important refinement. The read:write ratio determines which caching strategy, which database, and which scaling pattern fits the system:

• 100:1 or higher (read-heavy): Cache-aside or write-through is ideal. The cache hit rate will be high (because reads dominate and re-reads are common), and the cost of cache invalidation on writes is amortized across many reads. Most web apps (Twitter, Facebook, Instagram, news sites) are 100:1 or higher.

• 10:1 (moderate read): Cache-aside still works, but the cache hit rate is lower. Consider write-through to keep the cache fresher without doubling write load.

• 1:1 (balanced): Caching is less effective because writes evict/invalidate frequently. Consider write-behind (for coalescing) or skip the cache entirely. Analytics pipelines, message queues.

• 1:10 (write-heavy): Caching is rarely useful. The bottleneck is write throughput. Consider: write-behind for coalescing, LSM-tree databases (Cassandra) for write-optimized storage, partitioning by time/key, and eventual consistency. IoT telemetry, event logging, clickstream.

The deeper insight: read-heavy workloads are cache-friendly; write-heavy workloads are not. Many engineers apply cache-aside reflexively to every system, but for write-heavy workloads the cache hurts more than it helps (invalidation cost dominates). Knowing the read:write ratio before designing is essential.

In interviews, always split read and write QPS before discussing architecture. The interviewer is testing whether you recognize that the caching strategy depends on the ratio.

Estimating actions-per-user-per-day.

The hardest input to estimate is actions-per-user-per-day, because it varies enormously by system. Some reference points from real systems:

• Twitter: ~5 tweets/user/day for active posters; ~50 timeline reads/user/day for active readers.
• WhatsApp: ~50 messages/user/day; ~150 reads/user/day (each conversation generates many reads).
• Google Search: ~10-20 searches/user/day for heavy users.
• Netflix: ~1-2 hours of streaming/user/day = continuous low-QPS streaming.
• Instagram: ~50 feed reads/user/day, ~10 stories viewed, ~1-2 posts.
• YouTube: ~10 video plays/user/day.

For interview estimates, state your assumption explicitly and let the interviewer correct it. Wrong assumptions are fine; silent assumptions are not. The structure is: "I assume a typical user performs N actions per day — does that sound reasonable?"

A useful sanity check: if your estimated QPS implies more requests than there are internet users, you are wrong. The global internet has ~5B users; if your "search engine" QPS implies 100B searches/day, that is 20 searches per user per day on Earth — possible but high. Sanity-check your numbers against global scale.

The other sanity check: a single beefy server handles ~5-10k QPS for typical web workloads. If your estimate is 10 QPS, a single server is fine; if it is 1M QPS, you need 100-200 servers. The translation from QPS to instance count is the architecture decision the estimation is supposed to drive.

The QPS estimation interview step-by-step.

1. State DAU. "Assume 200M DAU for Twitter."
2. State actions/user/day, split by read and write. "Assume 5 tweets/user/day (writes) and 50 timeline reads/user/day (reads)."
3. Compute daily totals. Writes/day = 200M × 5 = 1B. Reads/day = 200M × 50 = 10B.
4. Convert to QPS. Write QPS = 1B / 86400 ≈ 11.5k. Read QPS = 10B / 86400 ≈ 115k.
5. Compute peak. Peak = avg × 3-5x. Write peak ≈ 60k. Read peak ≈ 575k.
6. Compute read:write ratio. 100:1 → cache-friendly.
7. Translate to architecture. "At 575k peak read QPS, we need a load balancer + ~100 app servers (assuming 5k QPS each) + Redis cluster (cache absorbs 90% of reads) + read replicas on the DB. Write QPS of 60k is high for a single DB; consider sharding or write-behind for counters."

The whole exercise takes 1-2 minutes if you have the conversions memorized. The conversions that matter: 1 day = 86400 sec (round to 100k for estimation); 1B/day ≈ 11.6k QPS; 1M/day ≈ 11.6 QPS.

The numbers do not need to be exact. They need to be reasonable and to drive a coherent architecture. An interviewer who hears "500k peak QPS → load balancer + 100 app servers + Redis cluster + read replicas" knows the candidate can connect numbers to design.

Mental model. Think of QPS Estimation as a deliberate boundary in a system. The boundary exists because something becomes harder to manage when everything is done in one place: latency, scale, failure isolation, consistency, cost, or team ownership. The useful question is not “what does QPS Estimation mean?” but “what pressure makes this boundary worth introducing, and what new failure mode does it create?”

Example: 10M requests/day ÷ 86,400 ≈ 116 requests/s average. Design for peak rather than average; a 10× peak is ≈ 1,160 requests/s.

Answer this without notes: When would you choose QPS Estimation, and when would you intentionally avoid it? Mention at least one bottleneck it addresses, one failure mode it introduces, and one alternative. Then quantify the workload you are designing for.

Numerical sanity check

Back-of-the-envelope reasoning beats fake precision. State your traffic, payload, concurrency and growth assumptions explicitly, then calculate enough to know whether the current architecture is orders of magnitude away from the target.