system-design · intermediate

Design Instagram — Photos, Feed, and Fan-Out

Start here

Design Instagram (simplified) means designing a service where users:

1. Upload photos
2. Follow other users
3. See a home feed of recent posts from people they follow
4. Open a post and view the image quickly worldwide

What you will learn

1. Clarify MVP vs out-of-scope features (Stories, Reels, DMs).
2. Estimate storage and QPS.
3. Design upload and view paths with object storage + CDN.
4. Compare fan-out on write vs fan-out on read for feeds.
5. Handle celebrity accounts without melting the system.
6. Discuss caching, ranking hooks, and failures.

What you should know first

Words you need before we begin

Requirements (interview style)

Functional (MVP)

• Register/login (auth can be shallow)
• Upload photo + caption
• Follow / unfollow
• Home feed (reverse chronological is fine for MVP)
• View post + image

Out of scope initially

• Recommendations, ads, Stories, live video, full search

Non-functional

• Uploads reliable; views low-latency globally
• Feed freshness seconds–minutes
• High availability for reads

Example scale (state assumptions)

• 500M DAU, 2 posts/user/day average → ~10k posts/s average (burst higher)
• Read:write on feed much higher than upload
• Images: 200 KB average after processing

High-level design

flowchart LR
  App[Mobile app] --> API[API gateway]
  API --> Upload[Upload service]
  API --> Feed[Feed service]
  API --> Graph[Graph service]
  Upload --> Obj[(Object storage)]
  Upload --> Meta[(Post metadata DB)]
  Graph --> GDB[(Follow graph store)]
  Feed --> FeedStore[(Feed cache / store)]
  App --> CDN[CDN] --> Obj

Step-by-step core design

Step 1 — Upload path

1. Client requests upload session.
2. API returns presigned URL to object storage.
3. Client uploads bytes directly (API not a bandwidth bottleneck).
4. Client confirms; service writes post metadata (userId, objectKey, caption, createdAt).
5. Async workers generate thumbnails / variants.

Step 2 — Follow graph

Store edges follower → followee in a graph-friendly store or sharded SQL/NoSQL. Query: list followees for user U; list followers for fan-out.

Step 3 — Feed generation options

Interview recommendation: hybrid.

Step 4 — Feed storage

Redis/streams or Cassandra-style timeline: feed:userId → [postId…] capped (e.g. last 1000). On open, hydrate post metadata from cache/DB; images via CDN URLs.

Step 5 — View path

Metadata cache by postId; image URL points to CDN → origin object store.

Step 6 — Celebrity path

If follower count > threshold, skip push fan-out; pull their posts at read time and merge into feed.

Complete worked example narrative

User A (1k followers) posts. System writes metadata, then enqueues fan-out job that pushes postId into 1k feed lists (batched workers). User B opens home: read feed list from Redis, batch-get post metadata, return JSON with CDN image URLs.

User C (20M followers) posts. System marks celeb path: no 20M pushes. Followers merge C’s recent posts when building feed.

Failure modes

Trade-offs

Common interview mistakes

1. Serving image bytes through the app server.
2. Ignoring celebrity fan-out.
3. Only saying “use Kafka” without feed model.
4. No CDN for media.
5. Perfect ranking before basic timeline works.

Check your understanding

1. Why presigned uploads?
2. Fan-out on write vs read in one sentence each?
3. How do celebrity accounts change the design?
4. What is stored in a feed list entry minimally?
5. Where do thumbnails get created?

Practice

1. Estimate storage for 100M new photos/day at 200 KB.
2. Draw sequence for upload + fan-out.
3. Pick a celebrity threshold and justify.
4. Design cache keys for post metadata.
5. Mock a 40-minute interview aloud.

Deeper production notes

Idempotent fan-out

Workers must tolerate retries without duplicating feed entries unboundedly—use set semantics or dedupe keys.

Privacy

Private accounts need authorization on graph edges and feed assembly—not only on upload.

Multi-region

Media CDN is global; metadata and fan-out often start single-region primary with eventual expansion.

Additional teaching scenarios

Scenario A — 10× peak

Scenario B — partial outage

Scenario C — interview wrap

Revision summary

• Separate bytes (object store + CDN) from metadata.
• Feed is a fan-out problem—use hybrid for celebrities.
• Optimize reads; async the heavy write fan-out.
• Discuss freshness, cache, and failure explicitly.

Glossary

Abbreviations and terminology

• CDN — Content Delivery Network
• DAU — Daily active users
• QPS — Queries per second

What to learn next

1. Feed timeline system design
2. Fan-out write vs read
3. Design WhatsApp
4. Caching 101

Extra teaching notes

When you apply this lesson, write the user-visible success metric first, then the failure mode you fear most. Design the smallest mechanism that protects that metric under partial failure. Prefer explicit timeouts, idempotency, and ownership over adding more infrastructure boxes.

In interviews or design reviews, narrate assumptions, request paths, and trade-offs out loud. A correct-enough design with clear failure handling beats a buzzword diagram without numbers. Revisit the worked example and restate it for a different domain to prove you own the ideas, not the template wording.

Extra teaching notes

When you apply this lesson, write the user-visible success metric first, then the failure mode you fear most. Design the smallest mechanism that protects that metric under partial failure. Prefer explicit timeouts, idempotency, and ownership over adding more infrastructure boxes.

In interviews or design reviews, narrate assumptions, request paths, and trade-offs out loud. A correct-enough design with clear failure handling beats a buzzword diagram without numbers. Revisit the worked example and restate it for a different domain to prove you own the ideas, not the template wording.

Extra teaching notes

When you apply this lesson, write the user-visible success metric first, then the failure mode you fear most. Design the smallest mechanism that protects that metric under partial failure. Prefer explicit timeouts, idempotency, and ownership over adding more infrastructure boxes.

In interviews or design reviews, narrate assumptions, request paths, and trade-offs out loud. A correct-enough design with clear failure handling beats a buzzword diagram without numbers. Revisit the worked example and restate it for a different domain to prove you own the ideas, not the template wording.

Extra teaching notes

When you apply this lesson, write the user-visible success metric first, then the failure mode you fear most. Design the smallest mechanism that protects that metric under partial failure. Prefer explicit timeouts, idempotency, and ownership over adding more infrastructure boxes.

In interviews or design reviews, narrate assumptions, request paths, and trade-offs out loud. A correct-enough design with clear failure handling beats a buzzword diagram without numbers. Revisit the worked example and restate it for a different domain to prove you own the ideas, not the template wording.

Extra teaching notes

When you apply this lesson, write the user-visible success metric first, then the failure mode you fear most. Design the smallest mechanism that protects that metric under partial failure. Prefer explicit timeouts, idempotency, and ownership over adding more infrastructure boxes.

In interviews or design reviews, narrate assumptions, request paths, and trade-offs out loud. A correct-enough design with clear failure handling beats a buzzword diagram without numbers. Revisit the worked example and restate it for a different domain to prove you own the ideas, not the template wording.

Interview and production field guide for this topic

Use this section as deliberate practice, not filler. Rewrite the worked example for a second domain you know well—fintech, education, logistics, or media. Keep the same skeleton: requirements, estimates, high-level diagram, request path, data model, scale lever, failure modes, and trade-offs. If you cannot fill every section without copying buzzwords, you do not yet own the design.

Numbers to force yourself to state

Always speak order-of-magnitude figures: peak QPS, storage growth per day, fan-out factor, connection counts, or queue depth. Wrong numbers that are explicit beat silent hand-waving. Correct the numbers when the interviewer or teammate challenges them; that is collaboration, not failure.

Failure minute

Set a timer for sixty seconds and list only failures: timeouts, duplicates, hot keys, dependency outages, bad deploys, and data corruption paths. For each, name detection and first mitigation. Designs that only describe the happy path are incomplete for production and weak in interviews.

Ownership and operability

Name the dashboard, the alert, the runbook section, and the team that pages. If any are blank, the system will train you during an incident. Prefer progressive delivery: canaries, flags, and rollback notes written before the change lands.

Consistency and retries

State whether the design assumes at-least-once delivery, whether handlers are idempotent, and where unique constraints live. Retries without idempotency are how double charges, double messages, and duplicate fan-out jobs appear. Timeouts without bounds are how thread pools die.

What good looks like in a review

A strong design review or interview answer clarifies scope, makes assumptions audible, draws a minimal path, deepens one or two bottlenecks, and closes with trade-offs and evolution. Use that bar on design-instagram round 0 every time you revisit it.

FAQ from first-time learners

Q: SQL or NoSQL for posts?
A: Either works for MVP; justify lookup by postId and by userId recent posts.

Q: Do I need ML ranking?
A: Mention as evolution; do not block MVP chronology.

Q: Kafka?
A: Useful for fan-out jobs and async pipelines—explain the consumer responsibility.

Track: Distributed Systems

Previous: Design Dropbox — File Sync and Storage

Next: Design Search Autocomplete — Typeahead Suggestions

By Shubham Jain

All articles · Study paths

Shubham Jain · Learning Lab