CodePark/ questions / Approaching a design interview
START PRACTICINGPRACTICE
Backend question · System design & architecture › Approaching a design interview

Do a back-of-envelope estimate for a photo-sharing app with these assumptions. Give average write QPS, read QPS, daily storage and yearly storage, and say what the numbers tell you.

10M daily active users
each user uploads 2 photos per day
each user views 50 photos per day
average photo size: 500 KB
1 day = 86,400 s (round to ~100,000 s for quick maths)

On average, expect about 230 writes per second and about 5,800 reads per second. Storage grows by about 10 TB per day.

Writes (uploads): 10M users x 2 uploads = 20M uploads per day. A day has 86,400 seconds. 20M / 86,400 = roughly 230 writes per second.

Reads (views): 10M users x 50 views = 500M views per day. 500M / 86,400 = about 5,800 reads per second.

Peak traffic: the busiest moments usually get 2 to 3 times the average. So plan for:

  • about 500 to 700 writes per second
  • about 12,000 to 17,000 reads per second

Storage: 20M photos x 500 KB = 10 TB per day. Over a year, that is about 3.65 PB. This is before replication (extra copies) and thumbnails.

What the numbers tell you:

  • The system is read-heavy, with about 25 reads for every write. So caching and a CDN (Content Delivery Network: servers near users that keep copies of files) matter most.
  • Photo bytes belong in object storage, like S3. The database stores only the metadata, such as owner, time and caption.
  • Write QPS (queries per second) is modest. So the metadata store is not the first bottleneck.
  • On average, expect about 230 writes per second and about 5,800 reads per second.
  • Plan for peaks of 2 to 3 times the average.
  • Raw photos need about 10 TB per day, or about 3.65 PB per year.
  • The read-heavy ratio points to a CDN and caching.
  • Store photo files in object storage and metadata in a database.