Design an Instagram-like photo-sharing application, focusing on **feed generation and delivery**. Your design should support: - Users creating posts containing photos or short videos. - Users following other users. - A home feed that shows recent and relevant posts from followed accounts. - High read traffic for feeds and high write fan-out for popular accounts. The core of the discussion is how posts travel from creation to a follower's home feed at scale, and how that pipeline behaves differently for an ordinary user versus a creator with millions of followers. ### Constraints & Assumptions Use these as anchors unless the interviewer steers otherwise — they are reasonable defaults for a problem of this size, not hard requirements: - The system is **read-heavy**: feed reads vastly outnumber post writes (a common rule of thumb is on the order of $100{:}1$ reads to writes). - Home feed reads should feel instant — target a low-tens-of-milliseconds server-side read latency. - **Eventual consistency is acceptable** for feed propagation: a new post appearing in followers' feeds a few seconds late is fine. - Posts and media must be **durably stored**; losing an uploaded photo is not acceptable. - Follower counts are highly skewed: most accounts have a modest following, but a small number of "celebrity" accounts have follower counts ranging into the millions. - Treat exact numbers (daily active users, post rate, media size limits) as things to confirm with the interviewer rather than guess. ### Clarifying Questions to Ask Before designing, scope the problem with the interviewer: - What scale are we targeting — daily active users, posts per day, and the average vs. peak follower count? - What is the read:write ratio, and how strict is the home-feed read latency SLA? - Is the home feed strictly **reverse-chronological**, or is **ranking / relevance** in scope? - How fresh must the feed be — is a few seconds of propagation delay acceptable, or do new posts need to appear immediately? - Are media uploads limited in size/format, and do we need transcoding for multiple resolutions or just storage + delivery? - Are likes, comments, and saves in scope, or should we focus only on post creation, the follow graph, and feed delivery? --- ### Part 1 — Core components and APIs Identify the services that make up the system and the public APIs a client uses to create a post, follow a user, and read a feed. ```hint What to enumerate List the distinct responsibilities and give each its own service — e.g. media upload/serving, post metadata, the **follow graph**, feed generation, and feed serving — rather than one monolith. For APIs, think about the endpoints behind *create post*, *follow/unfollow*, *read home feed*, and *read a profile feed*. ``` ```hint Pagination Feeds change constantly, so prefer **cursor-based pagination** over offset/page-number pagination to avoid skipped or duplicated posts as new content arrives. ``` #### What This Part Should Cover ```premium-lock What This Part Should Cover ``` ### Part 2 — Data flow from post creation to feed delivery Walk through what happens end to end: a user uploads media, creates a post, the post is stored, the feed pipeline reacts, and the post eventually surfaces in followers' home feeds. ```hint Where to start Trace one post's journey as an ordered sequence: media upload → post-metadata write → an event/signal that the post exists → feed-generation work → the read path that assembles a follower's feed. Be explicit about which steps are synchronous (in the request) vs. asynchronous (background). ``` ```hint Decoupling Consider emitting a `PostCreated` event onto a **message queue / log** (Kafka-style) after the post is durably written, so fan-out happens asynchronously and a slow fan-out never blocks the user's create-post request. ``` #### What This Part Should Cover ```premium-lock What This Part Should Cover ``` ### Part 3 — Storage choices for posts, media, follow graph, and feeds Choose appropriate storage for each kind of data and justify why a single store does not fit all of them. ```hint Match store to access pattern These four data types have very different shapes: large binary blobs (media), structured metadata (posts), relationships queried in both directions (the follow graph needs *who follows me?* for fan-out), and a per-user list of recent post references (the feed). Think **object storage + CDN** for media and a store whose access pattern matches each of the others; store **post IDs**, not full post objects, in the feed. ``` #### What This Part Should Cover ```premium-lock What This Part Should Cover ``` ### Part 4 — Push, pull, and hybrid feed generation strategies Compare fan-out-on-write (push), fan-out-on-read (pull), and a hybrid, and state the trade-offs of each. ```hint The core trade-off Ask **where each strategy pays its cost** — at write time or at read time — and what that does to write volume versus read volume. Then tie each regime to a follower-count profile. ``` ```hint Hybrid trigger A hybrid keys the decision on the **author's follower count**: below a threshold, push into followers' feeds; above it, skip the fan-out and merge those posts in at read time. Be ready to name roughly where that threshold sits and why. ``` #### What This Part Should Cover ```premium-lock What This Part Should Cover ``` ### Part 5 — Handling celebrities or creators with millions of followers Explain why the naive strategy breaks for very-high-follower accounts and how your design avoids it. ```hint What breaks A single celebrity post under a pure push model triggers **millions of feed-inbox writes** — write amplification that can saturate queues, caches, and databases during spikes. Identify this as the failure mode first. ``` ```hint A direction to consider Ask where a celebrity's posts could live so a follower retrieves them *on demand* instead of you pushing to everyone — and which fan-out strategy from Part 4 that corresponds to. Once you have that base, think about what makes the same hot posts cheap to serve repeatedly, and whether a partial push to a subset of followers helps. ``` #### What This Part Should Cover ```premium-lock What This Part Should Cover ``` ### Part 6 — Scaling database reads and avoiding feed-read bottlenecks Describe how the read path stays fast under heavy traffic and what you do to keep feed reads from becoming the bottleneck. ```hint Layers to apply Reach for the standard read-scaling toolbox and map each tool to a specific hot path: a **CDN** for media, **caching** for hot post metadata and celebrity outboxes, **read replicas** for relational stores, **partitioning** feed storage by `user_id`, and **batch reads** instead of one query per post. ``` ```hint Keep feed entries lightweight Because the feed inbox holds only post **references** (IDs + a score/timestamp), the read path batch-fetches post metadata separately and can cache it independently — keep the inbox bounded to the most recent N entries per user so it never grows unboundedly. ``` #### What This Part Should Cover ```premium-lock What This Part Should Cover ``` ### What a Strong Answer Covers ```premium-lock What a Strong Answer Covers ``` ### Follow-up Questions Be ready for the interviewer to push deeper: - How does your design change at $100\times$ scale — what is the **first component to break**, and how do you address it? - A celebrity posts and you want their followers to see it within seconds. Walk through exactly what happens with your hybrid approach — does the post appear fast enough? - How do you keep a user's home feed from showing **duplicate** posts when merging pushed inbox entries with pulled celebrity-outbox posts? - If feed ranking (relevance, not just recency) is required, where does the ranking step fit, and what signals would you use? - How do you bound the cost of a user who follows tens of thousands of accounts on the pull/merge path?