Photo and video sharing app: high-level design and peak server and storage sizing

You are asked to design a service similar to Instagram, where people share photos and videos, follow other accounts, scroll a feed of posts from the accounts they follow, and search for content. First sketch the high-level design; then estimate the servers and storage the service would need to handle peak traffic. ### Clarifying Questions - Which features are in scope: posting, following, the home feed and search, or also stories, messaging and live video? - Should the system serve one country or a worldwide audience, and how many daily active users should it be designed for? - Does "peak" mean the busiest hour of an ordinary day or a once-a-year spike such as a major holiday? - How long must uploaded photos and videos be kept? ### Part 1 — High-level design Describe the main components and walk through what happens when a user uploads a post and when a follower opens their feed. Explain where media files and post data are stored, how the feed is assembled, and how search finds posts. ```hint Split the bytes from the records Media files and post records differ enormously in size, access pattern and consistency needs; decide early where each one lives and how a phone reaches it. ``` #### What This Part Should Cover - Functional requirements plus realistic latency, availability and durability targets - The upload path and the feed-read path end to end, including media processing and delivery to the device - Storage choices for media files versus user, post and follow data, and how search is indexed ### Part 2 — Peak capacity estimate Estimate how many servers and how much storage the service needs at peak. State every assumption, show the arithmetic, and point out which inputs move the result most. ```hint Separate what accumulates from what spikes Storage grows with every upload that is ever kept, while servers must absorb the busiest second; estimate the two from different quantities. ``` #### What This Part Should Cover - Labeled assumptions for users, activity per user, media sizes and the peak-to-average ratio - Request rates, bandwidth, server counts and yearly storage computed with consistent units - Headroom for failures and replication, and a sanity check on the totals ### What a Strong Answer Covers - Scope and scale agreed with the interviewer before any design or arithmetic - Design choices justified by the service's read and write pattern rather than listed generically - Estimates that feed back into design decisions instead of standing alone - At least one explicit trade-off and a plan for degrading gracefully under peak load ### Follow-up Questions - How would the feed design change when an account with a very large following posts during the peak? - Which assumption most changes your server count, and how would you check it before launch? - How would you reduce storage cost for media that is rarely viewed after its first few weeks?