How Do You Estimate Traffic for a System Design Interview?
Learn back-of-the-envelope traffic estimation: deriving QPS, storage, and bandwidth from DAU and peak factors for interviews.
Expected Interview Answer
Traffic estimation is the practice of deriving concrete request-per-second, storage, and bandwidth numbers from rough business assumptions (daily active users, actions per user, growth rate) using back-of-the-envelope math, so a system design can be sized correctly rather than guessed at.
You start with a daily active user count and an estimate of how many requests each user generates per day, multiply them together to get total daily requests, and divide by 86,400 seconds to get an average requests-per-second figure. Because traffic is never flat, you then multiply the average by a peak factor (commonly 2x to 5x, depending on how spiky the domain is — e-commerce flash sales spike harder than internal tools) to estimate peak QPS, which is the number that actually drives provisioning. The same technique applies to storage: estimate bytes per record times records per day times retention period to project storage growth, and to bandwidth by multiplying request/response payload sizes by QPS. These estimates do not need to be exact — interviewers care that you show the reasoning chain and sanity-check the final number against something familiar (e.g., "that is roughly Twitter-scale" or “that is a few servers, not thousands”).
- Turns vague requirements into concrete numbers that drive real architecture decisions
- Surfaces which subsystem (compute, storage, or bandwidth) is the actual bottleneck early
- Demonstrates structured quantitative reasoning, a key signal interviewers look for
- Prevents wildly over- or under-engineered designs by grounding scale in evidence
AI Mentor Explanation
Traffic estimation is like a broadcaster estimating how many viewers will tune into a World Cup final before buying satellite bandwidth. They start with the country’s cricket-following population, estimate what fraction will watch on a given day, and divide by the match duration to get an average concurrent-viewer rate. Because viewership spikes hugely during the last over of a close finish, they multiply that average by a peak factor to size their broadcast capacity for the real crunch moment. Getting this rough number right before the match is far better than discovering the feed buffers during the final ball.
Step-by-Step Explanation
Step 1
Estimate daily active users and actions
Get or assume a DAU figure and an average number of requests each user generates per day.
Step 2
Compute average requests per second
Multiply DAU by actions-per-user, then divide by 86,400 seconds in a day to get an average QPS baseline.
Step 3
Apply a peak factor
Multiply average QPS by a domain-appropriate peak factor (typically 2x-5x) since real traffic is bursty, not flat.
Step 4
Extend to storage and bandwidth
Use record size x records per day x retention for storage, and payload size x QPS for bandwidth estimates.
What Interviewer Expects
- Shows the full reasoning chain from DAU to QPS rather than stating a number without derivation
- Explicitly distinguishes average QPS from peak QPS and explains why peak drives provisioning
- Applies the same back-of-envelope technique consistently to storage and bandwidth
- Sanity-checks the final number against a familiar reference scale
Common Mistakes
- Jumping straight to an architecture without deriving any traffic numbers first
- Sizing infrastructure to average QPS instead of peak QPS
- Forgetting units (seconds vs day) and getting orders of magnitude wrong
- Treating every domain as equally spiky instead of adjusting the peak factor to context
Best Answer (HR Friendly)
“Traffic estimation means taking rough numbers like how many users a product has and how often they use it, and doing simple math to figure out roughly how many requests per second the system needs to handle. You also account for the fact that traffic is not steady all day, so you multiply the average by a peak factor to plan for the busiest moments, not just a typical hour.”
Code Example
def estimate_traffic(
daily_active_users: int,
actions_per_user_per_day: int,
peak_factor: float = 3.0,
) -> dict:
total_daily_requests = daily_active_users * actions_per_user_per_day
seconds_per_day = 24 * 60 * 60
avg_qps = total_daily_requests / seconds_per_day
peak_qps = avg_qps * peak_factor
return {
"total_daily_requests": total_daily_requests,
"avg_qps": round(avg_qps, 2),
"peak_qps": round(peak_qps, 2),
}
# Example: 10M DAU, each performing 20 actions/day, spiky e-commerce domain
result = estimate_traffic(
daily_active_users=10_000_000,
actions_per_user_per_day=20,
peak_factor=4.0,
)
print(result) # avg_qps ~2314, peak_qps ~9259Follow-up Questions
- How would you choose a peak factor for a social media app versus an internal enterprise tool?
- How would you estimate storage growth for a photo-sharing service over five years?
- How does traffic estimation differ for read-heavy versus write-heavy systems?
- How would you validate your back-of-the-envelope numbers against real production data after launch?
MCQ Practice
1. What is the correct order of steps for a back-of-the-envelope traffic estimate?
The standard flow derives average QPS from usage assumptions first, then scales it up with a peak factor for provisioning.
2. Why is peak QPS more important than average QPS for provisioning?
Provisioning to average load leaves no headroom for the traffic bursts that actually cause outages.
3. What additional inputs are needed to estimate storage growth versus QPS?
Storage projections multiply record size by daily record volume and retention duration, distinct from request-rate math.
Flash Cards
What is traffic estimation? — Deriving request rate, storage, and bandwidth numbers from business assumptions using back-of-the-envelope math.
How do you get average QPS? — Multiply DAU by actions per user per day, then divide by 86,400 seconds.
Why apply a peak factor? — Real traffic is bursty; peak QPS (not average) is what infrastructure must be sized to survive.
How do you estimate storage growth? — Multiply bytes per record by records per day by the retention period.