Back-of-the-envelope estimate for a photo-sharing app

Use 1 day ≈ 86,400 s ≈ 10^5 s for quick sanity checks; use decimal units (1 TB = 10^9 KB).

Worked answer. (Decimal units: 1 MB = 1,000 KB, 1 GB = 10^6 KB, 1 TB = 10^9 KB.)

Uploads

• Photos per day = 10,000,000 × 0.2 = 2,000,000.
• Average upload rate = 2,000,000 ÷ 86,400 s ≈ 23 uploads/s.
• Traffic is uneven; assuming peak ≈ 3× average gives roughly 70 uploads/s.

Storage

• Per photo = 500 KB + 20 KB = 520 KB.
• Per day = 2,000,000 × 520 KB = 1,040,000,000 KB = 1.04 TB/day (one copy).
• Per year = 1.04 TB × 365 = 379.6 TB ≈ 380 TB.
• With 3 replicas = 379.6 × 3 = 1,138.8 TB ≈ 1.14 PB per year.
• Over five years ≈ 5.7 PB (ignoring growth) — clearly a job for object storage (e.g. S3-style), not a database.

Reads

• Average views = 23.15 uploads/s × 100 ≈ 2,315 reads/s; at 3× peak ≈ 6,900 reads/s.
• If every view fetched the full 500 KB image: 2,315 × 500 KB ≈ 1,157,500 KB/s ≈ 1.16 GB/s ≈ 9.3 Gbps of average egress.

What the numbers tell you

• Writes are modest (~70/s at peak), so a single well-provisioned metadata database with replicas can handle upload metadata.
• Storage and read bandwidth dominate. Serve images through a CDN so most views never reach your servers, and show thumbnails in feeds (20 KB instead of 500 KB cuts feed bandwidth by 25×).
• Store image bytes in object storage, and only metadata (photo ID, owner, URL, timestamp) in the database.

Self-check: 2 × 10^6 photos × ~0.5 MB ≈ 10^6 MB = 1 TB/day, which matches 1.04 TB.

Common follow-up / mistake: interviewers care more about reasonable assumptions and the order of magnitude than exact figures. A frequent slip is mixing bits and bytes in bandwidth (multiply bytes per second by 8 for bits per second), or forgetting replication when estimating storage cost.