1. The problem: why do you need a framework?

Imagine the interviewer says just one sentence: "Design Instagram." That is it. No spec, no numbers, no list of features. Instagram is a product with photo and video posts, Reels, Stories, a ranked feed, Explore, search, direct messages, notifications, shopping, live video and ads — built by thousands of engineers over more than a decade. You have 45 minutes.

Candidates without a method tend to fail in a few predictable ways:

• They start drawing immediately. Ten minutes later they have a detailed design for a feature the interviewer did not care about, and no time left for the part that mattered (usually the feed).
• They freeze. The problem is so big that they do not know where to begin, and silence fills the room.
• They recite buzzwords. "We'll use Kafka, Cassandra, Redis and Kubernetes" — without explaining why each is needed or what it costs.
• They never go deep. They draw twenty boxes and can't explain how any one of them actually works under load.

A framework fixes all four. It gives you an opening move (ask questions), a sequence that builds each decision on the previous one (requirements drive numbers, numbers drive architecture), and checkpoints where you can glance at the clock and adjust. It also signals seniority: experienced engineers do work this way in real design reviews.

2. The 6-step framework at a glance

Here is the whole method on one page. Each step produces an artifact that you leave visible on the whiteboard so that you and the interviewer can refer back to it.

The order matters because each step feeds the next. Requirements tell you what to estimate ("do we need to store video?"). Estimates tell you which architecture is necessary ("100K reads/s means we need caching and replicas; 1 PB/day of media means object storage plus a CDN"). The API tells you which services and data you need. The high-level design tells you where the risky parts are — and those become your deep dives.

3. Step 1 — Clarify requirements (≈ 5 minutes)

The prompt is deliberately vague. The interviewer wants to see whether you can turn ambiguity into a crisp problem statement — exactly what a senior engineer does when a product manager says "we want Stories". You need two lists:

• Functional requirements — what the system does (users can upload a photo; users see a feed of people they follow).
• Non-functional requirements — how well it does it: scale, latency, availability, consistency, durability, security, cost.

3.1 Narrow the scope out loud

You cannot design all of Instagram in 45 minutes, so propose a scope and let the interviewer correct you. A good opening sounds like this:

You:  "Instagram is huge, so let me propose a scope and you tell me if you'd
       like to change it. Core: users upload photos and videos with a caption;
       users follow other users; users see a home feed of posts from people they
       follow; users can like and comment. I'll treat Stories, DMs, search and
       Explore as extended features — I'll show where they plug in but won't
       design them in depth unless you want me to. Ads, shopping and live video
       are out of scope. Does that sound right?"
Interviewer: "Sounds good. Focus on the feed and uploads."
You:  "Great. A few questions about scale and quality..."

Notice what happened: you proposed instead of asking an open question ("what features do you want?"), which shows product sense and keeps control of the clock. The interviewer then told you where the signal is: feed and uploads. That one sentence decides your deep dives.

3.2 The questions worth asking

The detailed list of clarifying questions — with example answers — lives in the Requirements lesson.

3.3 Write the requirements down

Keep a corner of the board for this and never erase it. It becomes your contract: in step 6 you will walk back through it and show that every requirement is satisfied.

FUNCTIONAL (core)              NON-FUNCTIONAL
- upload photo/video + caption - 500M DAU, global
- follow / unfollow            - feed p99 < 300 ms (server), media via CDN
- home feed (ranked)           - 99.99% availability for feed & upload
- like / comment               - never lose an acknowledged upload
EXTENDED: stories, DMs, search - feed/likes: eventual consistency OK
OUT: ads, shopping, live       - read-heavy (~100:1 views : uploads)

4. Step 2 — Estimate the scale (≈ 3–5 minutes)

Back-of-the-envelope estimation converts the requirements into a handful of numbers that justify architectural decisions. The goal is the right order of magnitude, not precision. Round aggressively: 1 day ≈ 86,400 s ≈ 10⁵ s.

Assume 500M DAU.
Uploads:  100M posts/day  → 100M / 10^5 s ≈ 1,000 writes/s (peak ~3,000/s)
Feed:     each user loads ~20 feed pages/day → 10B/day → ~100K reads/s (peak ~300K/s)
Storage:  100M posts × ~1.5 MB (photo + renditions) ≈ 150 TB/day photos alone
          video makes it several hundred TB/day → object storage, not a database
Egress:   500M users × ~100 images × 200 KB ≈ 10 PB/day of images → CDN is mandatory

What each number tells you:

• ~100K–300K feed reads/s vs ~1K uploads/s → the system is read-heavy; optimise reads: pre-computed timelines, caches, read replicas.
• Hundreds of TB/day of media → blobs go to object storage, only metadata goes to databases.
• PB/day egress → a CDN must serve media; the origin could never handle it.

5. Step 3 — Define the API (≈ 3–5 minutes)

The API is the contract between clients and your system. Writing it down forces you to be concrete about what data flows where, and it reveals the services you will need. Keep it to the core use cases; you do not need every field.

# Upload: two-phase, so media bytes never pass through our app servers
POST /v1/media/upload-url        → { media_id, upload_url (pre-signed, expires in 15 min) }
PUT  {upload_url}                  (client uploads bytes directly to object storage)
POST /v1/posts  { media_ids[], caption, location? }   → { post_id, status: "processing" }

# Feed: cursor-based pagination
GET  /v1/feed?cursor=<opaque>&limit=20  → { posts: [ {post_id, author, media_urls[], caption,
                                                       like_count, liked_by_me, ...} ], next_cursor }

# Social graph
POST   /v1/users/{user_id}/follow
DELETE /v1/users/{user_id}/follow

# Engagement
POST   /v1/posts/{post_id}/likes          (idempotent: liking twice = one like)
POST   /v1/posts/{post_id}/comments  { text }
GET    /v1/posts/{post_id}/comments?cursor=

# Profile
GET  /v1/users/{user_id}/posts?cursor=

Points worth saying out loud while you write:

• Authentication comes from a token in the header, validated at the API Gateway — the user id is never trusted from the request body. See Authentication.
• Cursor pagination, not offset: new posts arrive constantly, so offsets would skip or duplicate items, and deep offsets are slow.
• Idempotency: mobile networks retry. A like or a post creation must be safe to repeat (idempotency keys, or "like" as a set-membership operation).
• Pre-signed upload URLs keep gigabytes of video off the app servers — detailed in Media Upload.
• Protocol choice: REST/JSON for public endpoints, gRPC between internal services, WebSockets for DMs — see API Design.

6. Step 4 — Data model + high-level design (≈ 10–12 minutes)

6.1 Data model first

List the core entities, their key fields and — most importantly — the access patterns (how they are read). The access pattern decides the database and the partition key, not the other way round.

Mention ID generation here: post ids should be globally unique and roughly time-sortable so "latest first" is a simple sort — Instagram's publicly described 64-bit ids (timestamp + shard id + sequence) are the classic example; see Unique ID Generation.

6.2 Draw the high-level design

Now draw boxes and arrows that satisfy every functional requirement end-to-end, at a single level of detail. Start simple and grow it, narrating as you go:

1. Client → load balancer → API gateway → services. One sentence each: the load balancer spreads traffic; the gateway does TLS, auth and rate limiting.
2. Split services by responsibility: Upload, Feed, Follow/Graph, Like & Comment, User. Make them stateless so they scale horizontally.
3. Attach a data store to each, using the table above.
4. Walk through the write path: upload bytes to object storage → create post → publish "post created" event to Kafka → workers resize/transcode, fan the post out to followers' timelines, index for search, send notifications.
5. Walk through the read path: feed service reads the timeline from Redis → hydrates post metadata (cache, then Cassandra) → returns JSON with CDN URLs → client fetches media from the CDN.

7. Step 5 — Deep dives (≈ 15 minutes)

This is where most of the technical-depth signal comes from. Pick 2–3 components that are (a) hardest, (b) most specific to this problem, and (c) of interest to the interviewer. For Instagram the usual candidates are:

7.1 How to run a deep dive

1. Ask or propose: "I think the feed is the most interesting part — shall I go deep there, or would you prefer the upload pipeline?"
2. State the sub-problem precisely: "We need each user's feed in <300 ms p99, at ~300K feed reads/s, where some authors have 500M followers."
3. Present 2+ options with a comparison (fan-out on write vs on read).
4. Choose one, with numbers ("push for 99.9% of authors; pull for the ~0.1% with more than ~1M followers — otherwise one celebrity post triggers hundreds of millions of writes").
5. Walk through failure cases: what if a fan-out worker crashes mid-way? (Kafka offsets → retry; idempotent writes to timelines.)
6. Close the loop by updating the main diagram.

8. Step 6 — Bottlenecks, trade-offs & wrap-up (≈ 5 minutes)

Finish strong. Walk the diagram looking for things that will break, then summarise.

• Single points of failure: is anything not replicated? Load balancers in pairs, databases with replicas and automated failover, services across availability zones. See Core Principles.
• Hot spots: a viral post's like counter, a celebrity's shard, a popular hashtag in search. Mitigate with sharded counters, caching and request coalescing.
• Failure handling: timeouts, retries with backoff, circuit breakers, graceful degradation ("if ranking is down, serve a chronological feed") — see Resilience Patterns.
• Consistency trade-offs you made: "feeds and like counts are eventually consistent; usernames are strongly consistent" — see CAP & Consistency.
• Operations: metrics, logs, traces, alerts on SLOs — Observability; disaster recovery and regions — Multi-Region.
• Future work: "With more time I'd design Explore ranking and multi-region active-active writes."

A crisp 60-second summary sounds like: "To recap: uploads go directly to S3 via pre-signed URLs; metadata in Cassandra sharded by user; an event on Kafka triggers media processing and a hybrid fan-out into Redis timelines; reads hit Redis and the CDN, so the read path never touches the primary databases in the common case. The main risks are celebrity fan-out and hot counters, which we handle with pull-on-read and sharded counters. We chose eventual consistency for feeds and counts to get 99.99% availability and low latency."

9. The 45-minute time budget

Most loops give you 45 minutes of design time (sometimes 60 with introductions). A typical plan, and what to do when you fall behind:

10. What interviewers evaluate

Companies use slightly different words, but nearly all rubrics boil down to five or six dimensions. Knowing them tells you what to make visible.

10.1 How expectations change by level

11. Communication tips

A design interview is a conversation with a colleague, not an exam you sit silently. The interviewer can only grade what they can hear and see.

11.1 Think aloud

Narrate your reasoning, including the options you reject: "I could store the feed in the database and query it on read, but at 300K reads/s with a join across hundreds of followees that would be far too slow, so I'll pre-compute timelines." The rejected option and the reason are often worth more than the choice itself.

11.2 Drive the conversation

• Announce the plan at the start: "I'll clarify requirements, do quick estimates, sketch the API, then the high-level design, and then go deep on the feed."
• Signpost transitions: "That covers the write path; now the read path."
• Offer choices instead of waiting: "I can go deep on fan-out or on media processing — which is more interesting to you?"

11.3 State assumptions explicitly

When you lack information, assume, say so, and move on: "I'll assume a ranked feed with eventual consistency; if it must be strictly chronological the design changes in this way…". Unstated assumptions look like gaps; stated ones look like judgement.

11.4 Check in, but don't ask permission for everything

Every few minutes: "Does this make sense so far? Anything you'd like me to focus on?" — but do not ask "should I use a cache?". Decide, justify, and let them push back.

11.5 Treat hints and pushback as gifts

If the interviewer asks "what happens when Cristiano Ronaldo posts?", that is a hint that your fan-out design has a hole. Do not defend the old design — say "good point, that breaks push fan-out; let me fix it" and adapt. Changing your mind in response to new information is a positive signal.

11.6 Keep the board organised

Requirements and numbers in one corner, API in another, the main diagram in the centre. Label arrows (sync vs async, what data flows). A tidy board makes your thinking easy to follow — and easy to grade.

12. How to discuss trade-offs

"Everything is a trade-off" is a cliché; the skill is making the trade-off specific. Use this template:

Applied to Instagram's feed:

"Options: fan-out on write (push), fan-out on read (pull), or hybrid. Criteria: our requirement is p99 < 300 ms at ~300K reads/s, and reads outnumber posts ~100:1. Decision: push, because each post is written once to ~200 average followers' timelines and then read many times cheaply. Cost: write amplification — ~100M posts/day × ~200 followers = ~20B timeline inserts/day — and wasted work for inactive followers; and celebrities with 100M+ followers would cause massive bursts. Mitigation: pull for accounts above a follower threshold and merge at read time; skip fan-out to users inactive for 30+ days. Revisit if the read:write ratio drops (e.g. a write-heavy product)."

The most common trade-off axes in system design:

13. A printable checklist / template

Print this (or memorise it) and run through it in every practice session until it becomes automatic.

SYSTEM DESIGN CHECKLIST                                         [ time ]
──────────────────────────────────────────────────────────────────────────
□ 0. Restate the problem in one sentence. Announce the plan.       0–2 min
□ 1. REQUIREMENTS                                                  ~5 min
     □ Users / actors?  Core use cases (3–5)?  What's out of scope?
     □ Scale: DAU, geography, growth.  Read:write ratio.
     □ Latency targets (p99) per key operation.
     □ Availability target.  Durability needs.
     □ Consistency per feature (strong where? eventual where?).
     □ Security / privacy / compliance.  Cost constraints?
     □ Write the list on the board. Confirm with interviewer.
□ 2. ESTIMATES (only what you'll use)                              ~4 min
     □ Read QPS and write QPS (avg and peak = 2–3× avg)
     □ Storage per day / per year (media vs metadata)
     □ Bandwidth in / out.  Cache size (hot set).
     □ Say what each number implies for the design.
□ 3. API                                                           ~4 min
     □ Core endpoints, inputs, outputs.  Auth.  Pagination (cursor).
     □ Idempotency for writes.  Sync vs async (202 Accepted).
□ 4. DATA MODEL + HIGH-LEVEL DESIGN                               ~12 min
     □ Entities, keys, access patterns → choice of store, partition key.
     □ Clients → DNS/CDN → LB → gateway → stateless services → stores.
     □ Async path: events → queue → workers.
     □ Walk the WRITE path and the READ path end-to-end.
     □ Every functional requirement covered?
□ 5. DEEP DIVES (2–3, agreed with interviewer)                     ~15 min
     □ State sub-problem + numbers.  ≥2 options compared.
     □ Decide + justify.  Failure cases.  Update the diagram.
□ 6. WRAP-UP                                                       ~5 min
     □ SPOFs, hot spots, bottlenecks → mitigations.
     □ Failure handling: timeouts, retries, degradation, DR.
     □ Monitoring / SLOs.  Security.  Cost.
     □ Trade-offs made.  Future work.  60-second summary.

14. How to practise

1. Learn the building blocks first. You cannot reason about trade-offs between components you don't understand. Work through Parts 1–5 of this guide (load balancers, caches, databases, sharding, queues, CDNs…).
2. Study one system deeply. This guide uses Instagram because it exercises almost every building block: media storage, feeds, graphs, counters, search, real-time messaging, notifications and ML. Once you can design Instagram end-to-end, systems like Twitter/X, TikTok, Facebook or Pinterest are variations.
3. Practise out loud, on a timer. Set a 45-minute timer and talk to an empty room, a rubber duck or a recording app. Reading designs silently trains recognition; speaking trains production — and the interview tests production.
4. Do mock interviews with a partner. Swap roles; being the interviewer teaches you what good answers look like. Ask for feedback against the rubric in section 10.
5. Review and redo. After each session, write down the two weakest moments (a question you couldn't answer, a step that ran over) and study exactly those. Redo the same problem a week later.
6. Vary the problem. Practise related prompts that reuse the same blocks: design Twitter's timeline, a chat app, a URL shortener, a notification system, YouTube, a rate limiter, a web crawler, a ride-sharing dispatcher.
7. Drill estimation separately. Five-minute daily drills ("how much storage do 1B tweets need?") build fluency with powers of ten — see Estimation.
8. Read real engineering write-ups (company engineering blogs, famous papers like Dynamo, Bigtable, TAO, Memcache at Facebook, The Tail at Scale) once you have the basics — they give you true, specific examples to cite.

15. How to use this guide: a learning path

The guide is organised as one architecture — Instagram — explained box by box. You can click any box on the interactive diagram to jump to its lesson, but if you are starting from zero, follow this order:

16. How Instagram uses the framework: mapping the steps onto the diagram

The architecture on this guide's home page is not a random collection of popular technologies — every box is the output of one of the six steps. The numbered badges below show which step "creates" each part of the design.

When you get "Design Instagram" in an interview, a strong performance in this guide's terms is:

1. Scope to upload + follow + feed + like/comment, flag Stories/DMs/search as extended (Requirements).
2. Size it: ~1K uploads/s, ~100–300K feed reads/s, hundreds of TB/day media, PB/day egress (Estimation).
3. Write 6–8 endpoints with cursor pagination and pre-signed uploads (API Design).
4. Draw the diagram top to bottom: clients, edge, services, Kafka, workers, stores, CDN (Request Flows).
5. Go deep on the feed (hybrid fan-out, Redis sizing, ranking) and media pipeline (News Feed, Media Processing).
6. Close with SPOFs, hot keys, consistency choices and a recap (Core Principles, CAP).

The complete minute-by-minute script is in the Full Interview Walkthrough.

17. Trade-offs & common pitfalls

Even the framework itself is a trade-off: structure versus flexibility.

The most common mistakes (and the fix)

• Jumping into the solution. Fix: always spend the first 5 minutes on requirements, even if you "know" the problem.
• Asking questions without proposing answers. "What scale?" → better: "I'll assume ~500M DAU globally — sound right?"
• Estimating numbers you never use. Every number must justify a decision (CDN, sharding, cache size), or skip it.
• Going deep too early. Designing the transcoding ladder at minute 12 means no feed at minute 40. Breadth first.
• Buzzword architecture. Naming technologies without explaining mechanics or need. Say what problem each box solves.
• One option only. Always mention at least one alternative and why you rejected it.
• Ignoring the hot path. For Instagram, the feed read path at ~300K req/s is where performance matters; spending equal time on the "change password" flow wastes signal.
• Forgetting failures. No discussion of what happens when a node, a zone or a dependency dies.
• Silent thinking. Long pauses with no narration — the interviewer can't grade thoughts they can't hear.
• Over-engineering. Multi-region active-active with consensus everywhere for a design that only needs a single region. Match complexity to requirements.
• Being defensive. Treat pushback as collaboration; adapt.
• No summary. Running out of time without a recap leaves the interviewer to assemble your design themselves.

18. Real-world technologies

In the interview you'll name concrete technologies. Use this "default toolbox" — and always say why:

19. Interview corner

20. Check your understanding

Related lessons

• Requirements — step 1 in depth, including the full list of clarifying questions
• Back-of-the-Envelope Estimation — step 2, with a complete worked Instagram example
• API Design — step 3: REST, gRPC, GraphQL, WebSockets, pagination, idempotency
• Core Principles — the vocabulary for step 6: scalability, availability, latency
• CAP & Consistency — how to discuss consistency trade-offs per feature
• News Feed — the most common Instagram deep dive
• Full Interview Walkthrough — the framework applied to Instagram, minute by minute