Estimate Storage for a Photo-Sharing App

What interviewers evaluate

• Do you decompose bottom-up (users → uploads → bytes) with explicit assumptions?
• Do you model skewed behavior (most users lurk) instead of assuming everyone posts?
• Do you know the engineering factors that dominate the answer (replication, derivatives, tiering)?
• Do you sanity-check the result per-user?
• Do you identify which assumption the answer is most sensitive to?

A framework to structure your answer

1. Scope - new storage per year for 10M DAU; photos only unless told otherwise (note video would dominate).
2. Uploads/day - model the skew: share of DAU who post on a given day × photos per poster.
3. Bytes/photo - original size plus serving derivatives (thumbnails, feed sizes).
4. Raw growth - multiply out to TB/day and PB/year.
5. Engineering overheads & savings - replication vs erasure coding, cold tiering, modern codecs.
6. Sanity check - per-user per-year figure; state the dominant sensitivity.

Try structuring your own answer first, then reveal a strong worked example.

Common variants

• Estimate the storage YouTube needs per day.
• Estimate the bandwidth a video-streaming service needs at peak.
• How many servers does a messaging app with 100M users need?

Pitfalls to avoid

• Assuming every DAU uploads daily - posting behavior is heavily skewed.
• Forgetting replication/durability overhead - it multiplies the answer 1.5-3x.
• Ignoring derivatives (thumbnails, transcodes) that add real bytes.
• Treating storage bytes and storage cost as the same thing (tiering breaks that link).
• No sanity check or sensitivity statement - a naked number invites the follow-up you can't answer.

Likely follow-ups

• Which assumption would you validate first with real data?
• How does the estimate change when the app adds 60-second videos?
• Finance wants the storage cost, not bytes. Walk me from PB to dollars.