Designing Instagram is really one hard question wearing a costume: how do you build the feed? Photo upload and following are warm-ups; the interview is decided by how you generate each user's home feed at scale — and whether you can reason about the fan-out trade-off. This walkthrough applies the standard system design framework to Instagram, with timings for a 45-minute round.
1. Requirements
Functional: upload a photo (with caption), follow/unfollow users, view a home feed of recent posts from people you follow, like/comment. Out of scope (say so explicitly to manage time): stories, DMs, explore/recommendations, ads.
Non-functional: read-heavy (people scroll far more than they post — about 20:1 with the assumptions below, and higher in practice), highly available, feed latency low (<200 ms), eventual consistency is fine (it's OK if a new post takes a few seconds to appear in followers' feeds).
2. Back-of-the-envelope
Assume 500M daily active users, each posting ~once/2 days and reading the feed ~10×/day.
- Writes (posts): ~250M/day ≈ ~3,000/sec. Reads (feed loads): ~5B/day ≈ ~58,000/sec → reads outnumber writes ~20:1, so the read path dominates.
- Media: ~250M posts/day × ~2 MB ≈ ~500 TB/day → photos live in object storage (S3) + CDN, never in the database. The DB stores metadata and pointers, not bytes.
3. API
POST /posts { imageData, caption } -> { postId }
GET /feed?cursor=... -> { posts[], nextCursor }
POST /follow { userId }
Feed pagination is cursor-based, not offset-based — offsets break when new posts shift positions.
4. Data model
Key tables/collections (access-pattern first): users, posts (postId, userId, mediaUrl, caption, createdAt), follows (followerId, followeeId), and a per-user feed cache. Posts and follows are simple lookups + time-ordered reads; a wide-column store (Cassandra) or sharded SQL both work.
5. The crux: generating the feed (fan-out)
This is where the interview is won. Two strategies:
| Strategy | How | Pros | Cons |
|---|---|---|---|
| Fan-out on write (push) | When you post, write the post id into every follower's precomputed feed list | Feed reads are O(1) and instant | A celebrity post writes to millions of feeds — a "thundering herd" |
| Fan-out on read (pull) | Build the feed at read time by querying recent posts from everyone you follow | Cheap writes; no wasted work for inactive users | Expensive, slow reads — especially if you follow many people |
The senior answer is a hybrid. Use push for ordinary users (precompute followers' feeds via an async worker/queue, so reads are instant), but for celebrities (millions of followers) switch to pull — their posts are fetched and merged into the feed at read time. You avoid both the write storm and slow reads. Naming this hybrid, and the celebrity threshold, is the moment that separates a strong candidate.
6. Putting it together
- Upload: client → app server → store image in S3 → write post metadata to DB → enqueue a fan-out job.
- Fan-out worker: reads the poster's followers, pushes the post id into each follower's feed cache (Redis), skipping celebrity accounts.
- Read feed: load the precomputed feed from cache, merge in recent posts from any celebrities you follow, hydrate post metadata, return image URLs that point at the CDN.
7. Bottlenecks & trade-offs to name unprompted
- Celebrity fan-out — the canonical hot-spot; the hybrid is the fix.
- Eventual consistency — a new post appearing a few seconds late is an acceptable trade for feed performance.
- Feed cache cost — precomputing feeds for hundreds of millions of users is expensive; cap stored feed length (e.g., latest 500) and regenerate inactive users' feeds lazily on read.
- Media delivery — CDN + multiple resized variants (thumbnail/feed/full) generated on upload.
- Ranking — we built reverse-chronological; a real feed adds ML ranking, which you can mention as a follow-up.
Why interviewers love this one
It forces the fan-out trade-off (no single right answer), separates media storage from metadata, and rewards reasoning about a read-heavy system at scale. It's the same framework as every other "design X" — see the URL shortener walkthrough for the simpler version of these moves.
Written by Amit Singh — Senior SDE at Amazon, Claude Certified Architect, and founder of AlgoEngineer. We teach this with live mock system-design interviews in our System Design course.