Design Instagram feed
Open the app and the newest posts from people you follow are already there. That list is your feed. Reading it has to feel instant, because nobody waits for a feed. Writing a post is different: it can take a few seconds to reach everyone, and the person who posted will never notice, because they already know what it says.
That difference is the whole design. Everything below moves work away from the moment someone reads and onto the moment someone posts. Then it deals with the one case where that stops working. Watch one post travel from the author to a follower.
Post. An author taps share. The request reaches the load balancer, which picks a server to handle it.
Three words come up all through this page:
- Fan out means copying one thing to many places. One post fans out to every follower's feed.
- Precompute means doing the work early, before anyone asks, so the answer is ready.
- Hydrate means turning a list of ids into the real posts by looking each id up.
This page builds the home feed of an app like Instagram. You follow accounts, a few accounts have tens of millions of followers, and opening the app shows posts from the people you follow. The numbers and choices below are interview assumptions, not Instagram's own. One real difference: Instagram has ranked its feed, rather than showing newest first, since 2016. That is exactly why this page keeps fetching the feed and ranking it as two separate layers.
Step 1: Understand the problem#
Six questions. One answer below decides the whole architecture and one of them is a trap. Find both before you draw anything.
| You ask | They say | What it settles |
|---|---|---|
| How many daily users, and how often does each one open the feed? | About 300 million, roughly ten opens a day. | How many reads there are for each write, and it is huge: tens of thousands of feed reads a second against a few thousand posts. Anything expensive has to move to the write side. |
| How fresh does a feed have to be? | A few seconds behind is fine. It must never be empty or out of order. | Permission to precompute. If every follower had to see a post the instant it was made, the work could not be done in the background, and every read would have to build the feed from scratch. |
| Chronological or ranked? | Newest first for now. | Fetching the feed becomes reading a sorted list of ids. Say you would keep fetching and ranking as separate layers, because ranking always arrives later and you do not want to rebuild the fetching part when it does. |
| What is the largest follower count? | Tens of millions. | The trap, and the second half of this page. One post turning into 40 million writes breaks the obvious design, and this answer is the warning. |
| Is a follow allowed to take effect a minute later? | Yes. | Follows can be handled in the background too, so no request ever has to rewrite a feed list while a user waits. |
| Do we store the photos and videos, or a reference to them? | A reference. Someone else owns the media pipeline. | Feed entries stay tiny, tens of bytes each, which is what makes it affordable to keep whole feeds in memory. |
"A few seconds behind is fine" has a name: eventual consistency. Followers will all see the post, just not at the same instant. The strong vs eventual consistency article shows the difference live. Getting this answer is what makes the rest of the page possible.
What you are building#
- Post something. Text and a media reference. The media pipeline is somebody else’s design question.
- Follow and unfollow. One way only: you can follow someone who does not follow you back. So a follow is not a friendship.
- Read your feed, newest first, a page at a time. This is 99% of the traffic and all of the speed budget.
- Feed loads in under 200ms for 95 out of 100 requests (p95).
- 300 million daily active users, opening the feed about 10 times a day.
- A post shows up for followers within a few seconds, not instantly.
- The feed can be slightly stale. It cannot be empty or out of order.
- Ranking and personalisation. Huge, and it sits on top of this rather than inside it. Say you would keep fetching separate from ranking.
- Media upload, transcoding and delivery.
- Notifications, which look similar and are a separate fan out problem.
- Ads, which are mixed into the feed at read time.
p95 means the 95th percentile: sort all request times, and 95% of them must be under 200ms. It is a better target than the average, because the average hides the slow requests real people feel. Tail latency at scale explains why the slow few matter so much.
Back of the envelope#
Before drawing boxes, count the work. (The method is in back of the envelope.) Here is a small version first, so the slider numbers below feel real.
Say Meera has 200 followers and posts one photo. If we precompute feeds, that one post becomes 200 small writes: put this post's id at the top of follower 1's list, follower 2's list, and so on. Now do that for everyone who posts today.
Reads are 34,722 a second, and each would be one simple lookup. The fan out turns one post into 200 writes, so the write side now does 10.0 times the work of the read side. That is the trade: you buy a fast read with an expensive write, and it works until one user has far more followers than the average.
Step 2: Propose the high level design#
The API#
Three calls cover everything in scope.
{
"text": "...",
"mediaId": "m_88123",
"clientId": "c_4f21ab"
}{ "targetId": 88231 }An idempotency key is a unique id the app attaches to one action. If the same request arrives twice because the phone retried, the server sees the same key and does the work only once. The idempotency keys article lets you try it.
The data model#
Two tables. The first is the truth. The second is a copy shaped for fast reading.
| post_id | bigint | PK | Snowflake style, so it sorts by time without a separate index. |
| author_id | bigint | IDX | For the profile page, which is a different query from the feed. |
| text | varchar(2048) | ||
| media_id | varchar(64) | A reference. Never the bytes. | |
| created_at | timestamp |
A Snowflake style id is a 64 bit number that starts with the time it was made, so sorting ids also sorts posts by time. How to build one without two servers handing out the same number is a whole question: design a unique ID generator.
| user_id | bigint | PK | The reader, not the author. This is the whole point. |
| post_ids | list<bigint> | Newest first, capped at about 800 entries. Ids only, never post content. |
The feed table lives in Redis, an in-memory store where reading a list takes about a millisecond. Keeping a ready made answer in memory in front of the real data is caching, and caching patterns covers how it fails. "Sharded by user_id" means the users are split across many machines, each machine holding some of them; the sharding chapter starts from zero.
The cap of about 800 matters. Nobody scrolls past a few hundred items, so trimming the list keeps storage bounded and the write cheap. If someone does scroll to the end, build older pages on demand. That is rare enough to be allowed to be slow.
The whole system on one whiteboard#
Figure 1 is the picture at the top of the page, with the last few pieces added.
Walking Figure 1:
- A request arrives at the load balancer, which spreads requests across many identical servers so no single one is overloaded. (Load balancing covers how it picks.)
- For a new post, the post service writes it once, to the post store, and returns. The author is not waiting for anything else.
- It drops a small job on the fan out queue: just the post id. A queue is a waiting line between two parts of the system. The post service puts work in, workers take it out whenever they are free. Here it is Kafka, split into partitions by post id. The message queues chapter explains partitions, and queue vs pub/sub vs event stream explains where Kafka sits among them.
- Fan out workers pick the job up and ask the follower graph who needs to see it.
- For each follower, the worker pushes the post id onto that follower's list in the feed store. This is the expensive step, and it is the reason the queue sits in front of it.
- On the other side, a feed read is a list lookup. Ids come out of the feed store already in order.
- The feed service merges in anything that was deliberately not fanned out. That is how accounts with tens of millions of followers are handled, explained two sections down.
- The ids are hydrated into posts in one batch call to the post store, photos and videos come from the media CDN (servers near the user that hold copies of the files), and the response goes out.
The queue does more than separate the two sides. It soaks up the burst when a popular account posts. It lets fan out be retried on its own if it fails, without touching the post. And it means the post is safely stored before any of the expensive work starts.
Step 5 of the walk above is one write per follower. A celebrity with 40 million followers posts. What exactly goes wrong, and would adding workers fix it?
Step 3: Design deep dive#
Push, pull, or both#
Think of a newspaper. Push is the paper boy who drops a copy at every subscriber's door the moment it is printed: reading is instant, delivery is a lot of walking. Pull is you walking to every shop that sells the papers you like, each morning, and reading them there: nothing is delivered, but your morning is slow. Feeds face the same choice. The push vs pull article puts this case next to four others.
When someone opens the app, where does their feed come from?
- First tryBuild it when they open the app (pull, or fan out on read)Store nothing extra. When a user opens the app, look up the 200 accounts they follow, fetch each one's recent posts, merge them newest first, and return the top 20. Posting costs nothing, and no work is wasted on users who never open the app.Where it breaks: Every single feed open becomes 200 lookups that must all come back before the page can show. At 35,000 opens a second that is millions of lookups a second, and the slowest of the 200 decides how long the user waits. The 200ms budget is gone.
- BetterBuild it when someone posts (push, or fan out on write)When Meera posts, write her post id into the precomputed list of each of her 200 followers. Opening the app is now one list read plus one batch hydrate. This is as fast as a read can be.Where it breaks: It assumes follower counts are modest. An account with 40 million followers turns one post into 40 million writes, which jams the queue for everybody. The next two sections are about exactly this.
- What you shipPush for almost everyone, pull for the few huge accounts (hybrid)Below a follower threshold, push. Above it, do not fan out at all. When a user opens the app, read their precomputed list and merge in the recent posts of the few huge accounts they follow. That merge touches a handful of accounts, not 200, so it stays fast.
Here are the three shapes side by side.
Why the celebrity breaks it#
Fan out on write is sized from the average follower count. The trouble is that follower counts do not cluster around an average. They follow a power law: most accounts have a handful of followers, a few have millions, and the few at the top are so far out that the average describes nobody. Switch between the two views below.
The first chart says "fan out is cheap". The second says "a few accounts do most of the work, all at once". A design sized from the first is broken by the second.
Make it concrete. An account with 40 million followers posts once. That is 40 million list writes from one request, and it lands as one burst.
An account with 40 million followers just posted. What do you do?
- First tryAdd more fan out workersThe queue is backing up, so add machines to drain it faster.Where it breaks: You are not short of machines, you are short of a reason to do 40 million writes. The work is real. While it runs, everyone else's posts sit in the queue behind this one (head of line blocking), and the last follower sees the post minutes after the first.
- BetterGive big accounts their own queue partitionRoute posts from large accounts to a separate partition with its own workers, so a big post cannot block normal posts.Where it breaks: Normal users are safe again, which is worth keeping. But the 40 million writes still happen, still cost the same, and the celebrity's followers still get the post over minutes.
- What you shipDo not fan out above a threshold. Merge at read time insteadWrite the celebrity post once and stop. When a follower opens the app, the feed service fetches recent posts from the few huge accounts they follow and merges them into the precomputed list. Keep the separate partition for accounts that are large but below the threshold.
"Where do you set the threshold?" Not from first principles. It is where fan out cost crosses read merge cost, and that depends on your read to write ratio and how many celebrities a typical user follows. Start somewhere defensible, around ten to a hundred thousand followers, measure both paths, and move it. Saying you would measure it is a better answer than a confident number, because a confident number here is invented.
Keeping the feed correct#
The feed lists are derived data: a copy built from the posts and follows tables. Copies drift away from the truth over time, so plan for the four ways this one drifts.
Unfollow. Their posts are already sitting in your list. The usual answer is to filter at read time: when hydrating, you have each post's author id anyway, so drop posts from people you no longer follow. Unfollows are rare, so this costs almost nothing.
Deleted posts. Same shape. The id stays in feed lists, and hydration finds nothing for it. So the read path has to skip gaps and fetch a few extra ids to fill the page.
A new follow. Your list has none of that person's older posts. Either copy their recent posts into your list (backfill), or let the feed fill in going forward. Backfilling feels nicer, and it is a product decision worth naming.
Rebuilding. Treat feed lists like a cache whose miss is expensive. You need a job that can rebuild one user's feed from the posts and follows tables, for when a list gets corrupted or the retention rules change. If you cannot rebuild it, the copy has quietly become a second source of truth, and now you have two.
Break it#
Push the load up one level at a time and watch which box goes red first.
Read every step as text
- typical · Healthy. Average author, 200 followers. About 350,000 feed writes a second across the fleet, spread evenly. The queue is nearly empty and posts land in followers’ feeds in under a second.
- popular post · Degraded. An account with 200,000 followers posts. One request becomes 200,000 writes. The workers absorb it and the queue drains in a few seconds, but everyone else’s posts are slower because they are queued behind it.
- celebrity posts · Down. 40 million followers, one post. The queue fills with one message’s worth of work and every other post in the system waits behind it. The last follower sees the post minutes after the first. More workers do not help, because the work is real and the queue is blocked at the front.
- hybrid · Healthy. Above the threshold, do not fan out at all. The post is written once and merged into feeds at read time for the people who follow that account. Fan out load is back to normal, celebrity posts appear right away instead of over minutes, and the read side pays a small, bounded cost.
Trade-offs#
| Choice | What you gain | What you pay | Pick it when |
|---|---|---|---|
| Fan out on write | A feed read is one list lookup, which is the fastest this can be and scales with cheap read capacity. | One post becomes N writes, and work is wasted on users who never open the app. | The default for the vast majority of accounts, where N is small. |
| Fan out on read | Nothing stored, nothing to rebuild, and no wasted work. Always current. | Every read gathers from hundreds of authors, which is where your latency budget dies. | Celebrity accounts, and users who are rarely active enough to justify precomputation. |
| Storing post ids in feeds | Bounded storage, and editing or deleting a post takes effect everywhere at once. | A second round trip to hydrate, and the read path has to cope with ids that no longer resolve. | Almost always. Storing content per follower multiplies storage by follower count. |
| Capping feeds at a few hundred entries | Storage and write cost stay bounded no matter how long an account exists. | Deep scrolling falls back to a slower on demand path. | Always. The number of users who scroll past a few hundred items is small enough to serve slowly. |
Interview replay#
Checkpoint#
1. Why does adding more fan out workers not solve the celebrity problem?
2. Why store post ids in each feed rather than the post content?
3. A user follows 5,000 accounts and the feed read is now slow. What is the most likely cause?
- 300 million users opening ten times a day is about 35,000 feed reads a second, against a few thousand posts.
- One post from an account with 40 million followers is 40 million list writes. Adding workers does not fix it.
- A feed entry is an id and a timestamp, tens of bytes. That is why whole feeds live in memory.
- Push for everyone, pull for the few hundred accounts big enough to break it. The hybrid is the answer.
Reads dominate and nobody waits for a feed, so I would move the work to write time: when someone posts, fan out the post id into a precomputed list for each follower, capped at a few hundred entries. A feed read is then one list lookup plus a batch hydrate of posts by id, and both are cacheable. That model breaks on accounts with huge follower counts, because one post becomes tens of millions of writes and blocks the fan out queue for everyone else, so above a follower threshold I stop fanning out and merge those authors at read time instead. Feed lists store ids only, so edits and deletes take effect in one place, and unfollows and deleted posts are filtered during hydration rather than scrubbed from every list. Ranking sits on top as a separate stage, so it can change independently and fall back to newest first if it fails.