Design Instagram

Design a photo-sharing service like Instagram. Users upload photos with captions, follow other users, and scroll a home feed of photos from the people they follow.

1. Clarify the requirements

Before drawing anything, ask questions. These are the answers an interviewer would typically give:

How many users?

500 million daily active users.

Which features?

Upload photos, follow users, and see a home feed. Likes and comments are nice to have; stories, DMs and video are out of scope.

How is the feed ordered?

Reverse chronological is fine for this interview; mention ranking as an extension.

Read vs write ratio?

Very read-heavy: people view far more photos than they upload (about 100 views per upload).

Latency?

The feed should load in under 200 ms. A new post may take a few seconds to appear in followers' feeds.

Photo size?

About 2 MB on average after client-side compression.

2. Estimate the scale

Assumptions: 500M DAU. 10% of users upload 1 photo a day (2 MB each). Each user views 100 photos a day.

• Upload QPS: about 579 uploads/s500M × 10% ÷ 86,400 ≈ 580 uploads/s.
• Photo view QPS: about 579K views/s500M × 100 ÷ 86,400 ≈ 580K views/s.
• New storage per day: about 100 TB50M uploads × 2 MB = 100 TB/day.
• Storage for 5 years: about 182.5 PB100 TB × 365 × 5 ≈ 180 PB (before replication).

3. The high-level design

1. Users reach stateless API serversEvery request enters through a load balancer that spreads it over stateless API servers, so adding servers is how you scale.
2. Photos live in object storagePhotos are large and never change: clients upload them straight to object storage with a pre-signed URL. The API only stores who posted what.
3. A CDN serves the photosMost traffic is photo views. A CDN serves them from servers close to users, so the origin barely notices.
4. Metadata in a sharded databaseUsers, posts and follows go in a database sharded by user_id, with read replicas that take over if the primary dies.
5. Precomputed feeds in a cacheEach user's feed (a list of post IDs) sits in a cache, so opening the app is one fast read.
6. Fan-out in the backgroundA new post becomes a job on a queue. Workers push its ID into followers' feeds, except celebrities, whose posts are merged when a feed is read (hybrid push/pull).
7. Watch it in productionMetrics and alerts close the loop: feed p99, fan-out lag and cache hit ratio.

4. The components and what each one does

Users Client (web)

Mobile and web apps.

Load balancer Load balancer

Spreads requests over the stateless servers behind it, health-checks them and routes around a dead one. Rate limits abusive clients.

API servers App servers

Stateless: any server can handle any request, so you scale out horizontally. Checks the auth token on every request.

Photo storage Object storage · S3

Originals and resized versions (S3-like). Uploaded directly with a pre-signed URL.

CDN CDN

Serves photos from the edge; object storage is the origin.

Users, posts & follows SQL database · PostgreSQL

Sharded by user_id; primary + read replicas with failover.

Feed cache Cache · Redis

Per-user feed: the latest post IDs, precomputed by fan-out.

Fan-out queue Message queue

One job per new post.

Fan-out workers Workers

Fan-out on write for normal users; celebrities use fan-out on read (hybrid).

Metrics & alerts Metrics & alerts

Dashboards and alerts on p99 latency, error rate, queue depth and cache hit ratio, so a bottleneck shows up before it becomes an outage.

5. Deep dive: feed generation & fan-out

How does a new photo get into followers' feeds? Compare fan-out on write (push) and fan-out on read (pull), and handle users with millions of followers.

• Push: on upload, write the post ID into each follower's feed cache. Fast reads, expensive for celebrities.
• Pull: build the feed at read time by querying followed users. Cheap writes, slow reads.
• Hybrid: push for normal users, pull for celebrities, merge at read time.

6. What interviewers listen for

• Upload APIDefine how a client uploads (ideally to object storage via a pre-signed URL).
• Paginated feed APIFeeds are infinite; paginate with a cursor so each request is cheap.
• Data model: users, posts, followsName the entities and their keys; it drives the database choice and sharding.
• Push vs pull, hybrid for celebritiesThis is the key trade-off of any feed. Push is fast to read but explodes for celebrities; pull is the reverse; hybrid gets the best of both.
• Shard key for posts/feedsSharding by user ID keeps a user's posts together; mention hot users.
• Feed ordering / rankingSay how the feed is ordered, even if it's just reverse-chronological for now.
• Database replication and failoverA single database is a single point of failure. Replicas give redundancy and read capacity; failover promotes a replica when the primary dies.
• Partition (shard) data as it growsOne machine eventually can't hold the data or the write load. Say how you'd split it and by which key.

7. Follow-up questions

1. A celebrity with 300 million followers posts a photo. Walk me through exactly what your design does.
2. One photo goes viral and gets a million likes a minute. How do you count likes without melting the database?
3. Your CDN has an outage in Europe. What happens when European users open the app?
4. Users on weak mobile networks say uploads of large photos keep failing. What would you change?

The design in a nutshell

• Clients → DNS → load balancer → stateless API servers.
• Upload: client gets a pre-signed URL and uploads to object storage; API stores metadata (post_id, user_id, caption, created_at) in a sharded DB.
• Publishing a post enqueues a fan-out job; workers push post IDs into followers' feed caches (skip celebrities).
• Feed read: get post IDs from the feed cache, merge celebrity posts, hydrate from post/user caches, images via CDN.
• Replicated DBs, cache invalidation on edit/delete, monitoring of fan-out lag and p99 feed latency.

Related lessons: Fanout on write vs fanout on read · Deep dive: the fanout service · Deep dive: news feed retrieval and the cache layers