You're asked in an interview to estimate the average and peak queries-per-second (QPS) for a social app with 10 million daily active users (DAU), where each user makes about 20 read requests per day. Walk through how you'd compute average QPS and peak QPS, and why the two numbers differ.

## Why this is the opening move Back-of-envelope QPS estimation is usually the opening move of a system design interview because it turns a vague business description - 'a social app with 10 million users' - into a concrete number that drives every downstream decision: - how many application servers to provision - whether a single database instance can survive the read load - how big a cache needs to be - how much headroom to build into autoscaling policies The mechanism itself is simple unit conversion, but doing it cleanly and defending the assumptions under interview pressure is a distinct skill from knowing the formula. ## The arithmetic, in two steps 1. **The first step** is defining the input clearly: daily active users (DAU) times actions per user per day gives total daily events. Here that's `10,000,000` users x `20` requests = `200,000,000` requests per day. 2. **The second step** converts that daily total into a rate by dividing by the number of seconds in a day. A day has `86,400` seconds, but experienced candidates round this to `100,000` in their head for faster arithmetic, since the resulting 15% error is irrelevant at the order-of-magnitude precision system design cares about. `200,000,000 / 100,000 = 2,000` QPS average (the precise figure is about 2,315, but 2,000 is close enough to reason with). This average is a useful baseline but it is not what you provision for, because it assumes requests are spread perfectly evenly across every second of the day, which no real traffic pattern does. ## Why peak runs ahead of average The reason average QPS understates what infrastructure must handle is that human activity follows a **diurnal curve**: usage is near zero at 3am local time and spikes during commute hours, lunch breaks, and evening leisure time. - If a service has users concentrated in a few time zones, the ratio between the busiest hour and the average hour can be large. - Globally distributed user bases smooth this out somewhat because peaks in one region overlap with troughs in another, but even global consumer apps commonly see peak hourly traffic at 2-3x the daily average. - Some verticals (news during breaking events, e-commerce during flash sales, ticketing at on-sale time) see peak-to-average ratios of 10x or more. The standard interview move is to apply a **peak factor** - 2x as a conservative floor, 3x as a common assumption absent better data - directly to the average QPS figure. Multiplying `2,000 x 2.5` gives roughly `5,000` peak QPS, which is the number that should actually inform capacity planning, since provisioning for the average would mean the system falls over precisely when it matters most: the busiest moments. ## The trade-off: rigor against the interview clock The trade-off inherent in this exercise is between analytical rigor and interview-clock speed. A perfectly rigorous answer would pull the real hourly distribution of traffic from historical monitoring data, fit it, and derive an exact peak-to-average ratio; interviews don't allow for that, so the accepted practice is to state an assumed multiplier explicitly, flag it as an assumption open to correction with real data, and move on. Failing to flag it - presenting the 2-3x figure as fact rather than a working assumption - is a common tell that a candidate is pattern-matching a memorized script rather than reasoning about the specific system in front of them. ## The failure mode in production The failure mode in production, correspondingly, is capacity planned entirely off an average QPS number: teams that provision for average load routinely discover their real ceiling only during an actual traffic spike, when requests start queueing, latency balloons, and the system degrades or falls over exactly during the highest-value traffic window (a product launch, a viral moment, Black Friday). A concrete real-world illustration: Twitter's engineering team has historically discussed handling roughly hundreds of thousands of tweets per minute in steady state, but has publicly described enormous multi-fold spikes during global events like World Cup matches or New Year's Eve, where their systems had to absorb traffic many times the baseline within seconds - exactly the peak-vs-average gap this exercise trains you to reason about before you ever touch a whiteboard architecture diagram. ## What is actually being tested The skill being tested is not the arithmetic itself but the instinct to ask 'peak or average?' before quoting a single QPS number, because every subsequent capacity decision in the interview - server count, database sharding, cache sizing - should be anchored to peak, with average kept around only as the number you'd use for cost estimation and steady-state resource utilization targets.