Practice — System Design Interview Framework & Capacity Estimation (5 questions)

You are asked to design a photo-sharing service. After clarifying requirements you have agreed these assumptions with the interviewer:

• 200 M monthly active users, 50% active on any given day
• Each active user uploads 0.5 photos/day and views 50 photos/day
• A stored photo (with two thumbnails) averages 600 KB; metadata is ~300 B
• Retention: 5 years

1. Compute average and peak (assume 3× average) upload QPS and view QPS.
2. Estimate storage growth per day and the total after 5 years, split into media and metadata.
3. Using the 80/20 rule, size a cache for the day's popular photos, and say which number in your estimate points to the hardest part of the design.

The interviewer says: "Design a system like Google Docs." Nothing more.

1. Write the 4–6 clarifying questions you would ask in the first five minutes, and for each say which design decision the answer changes.
2. Propose a functional scope (in-scope and explicitly out-of-scope) for a 45-minute interview.
3. State the non-functional requirements you would assume if the interviewer says "you decide", with a one-line justification each.

A product page must render in under 200 ms at p99 (server side). The request path is: load balancer → API service → (a) product cache lookup, on miss a database read, → (b) a call to a pricing service in the same datacenter, → (c) a call to a recommendations service hosted in another region.

1. Using the standard latency reference numbers, estimate the cost of each hop and decide whether the 200 ms budget is achievable.
2. Propose two changes, justified with numbers, that would make the budget comfortable.
3. If the pricing service is 99.9% available and the API service is 99.95% available, what availability can the product page promise if it fails whenever either fails?

During a news feed design you said: "I'll precompute each user's feed on write (fan-out on write)."

1. Restate that decision using the four-part trade-off template (choice, alternative, deciding requirement, accepted cost/mitigation), referencing numbers from a Twitter-like estimate (150 M DAU, 300 M posts/day, ~100:1 read:write, average 200 followers).
2. The interviewer changes a requirement: "Assume this is a professional network where posts are rare (0.05/user/day) and most reads come from a handful of hugely followed publishers." Re-decide, using the same template.
3. Name two failure modes of your original design and how you would detect and handle each.

Your estimate for an API says 40,000 requests/s average and 3× at peak. A single application server comfortably serves ~2,000 requests/s; the relational primary can absorb ~5,000 writes/s; 10% of requests are writes.

1. How many application servers do you deploy, and why more than the raw division suggests?
2. Is a single database primary enough for the writes? What would you say about reads?
3. The product team wants a 99.99% availability SLA. Translate that into downtime per year and name three concrete design consequences.