1. The problem: why a script for "Design Instagram"?

"Design Instagram" (or its cousins "design a photo-sharing app" and "design a news feed") is one of the most frequently asked system design questions, because it touches almost everything: a read-heavy feed, a write-heavy engagement layer, huge blobs, a social graph, search, real-time messaging and async pipelines. It is also open-ended. Without structure, candidates spend 20 minutes on login screens or draw boxes without numbers. Then the clock runs out before the interesting part, the feed.

Every concept in this walkthrough has its own lesson in this guide. Here we practise assembling them under time pressure, in the order and at the depth an interviewer expects. The framework is the one from How to Approach a System Design Problem; the numbers come from Back-of-the-Envelope Estimation; the request paths come from End-to-End Request Flows.

2. The 45-minute plan

3. Minutes 0–5: Clarifying questions

Never start designing immediately. Ask a few, high-leverage questions, and propose answers yourself when the interviewer turns the question back to you ("What do you think?"), which they often will.

4. Minutes 5–8: Requirements

Write these on the board. They are the contract you'll check your design against at the end (see requirements).

This is a direct application of CAP/PACELC. During a partition we choose availability for the feed. In normal operation we choose latency over consistency for everything except auth, privacy and DMs ordering.

5. Minutes 8–12: Capacity estimation

State assumptions, round aggressively, and focus on numbers that change the design. Full derivations are in capacity estimation; here is the summary a candidate would put on the board.

Assumptions: 500M DAU · 100M new posts/day · each DAU opens feed ~10×/day
             each DAU likes ~10 posts/day · avg original photo 2 MB, renditions +0.5 MB
             avg follower count ~200 (heavy skew: a few accounts have 100M+)

Writes  (posts):   100M / 86,400 s        ≈ 1,200 posts/s     (peak ~3–5k/s)
Reads   (feed):    500M × 10 / 86,400     ≈ 58,000 feed req/s (peak ~150k/s)
Likes:             500M × 10 / 86,400     ≈ 58,000 likes/s
Fan-out writes:    1,200 posts/s × 200    ≈ 240,000 timeline inserts/s (avg)

Media storage:     100M × 2.5 MB          = 250 TB/day ≈ 90 PB/year (before replication/EC)
Metadata:          100M × ~1 KB           = 100 GB/day ≈ 36 TB/year
Timeline cache:    500M users × 500 IDs × 8 B = 2 TB raw (~5–6 TB with Redis overhead)
                   → ~100 Redis nodes × 64 GB, plus replicas
Media egress:      500M × 100 images × 200 KB = 10 PB/day ≈ 1 Tbps avg (CDN absorbs 95%+)

6. Minutes 12–16: API design

Keep it to the endpoints that matter, and show you know the details that separate good APIs from naive ones: cursor pagination, idempotency keys, pre-signed uploads and authentication (see API design).

# All calls: HTTPS, Authorization: Bearer <JWT>, JSON. Versioned under /v1.

POST /v1/media/uploads            {type, size_bytes, sha256}
  → 200 {media_id, upload_url (pre-signed PUT, expires 15 min)}

POST /v1/posts                    {media_ids[], caption, location_id?, user_tags[]}
  Headers: Idempotency-Key: <uuid>
  → 201 {post_id, created_at, status: "PROCESSING"}

GET  /v1/feed?cursor=<opaque>&limit=20
  → 200 {posts:[{post_id, author, caption, media:[{url_640, url_1080, w, h}],
                 like_count, comment_count, viewer_has_liked}], next_cursor}

GET  /v1/users/{user_id}/posts?cursor=...&limit=30     # profile grid

PUT    /v1/posts/{post_id}/like                    → 204   (idempotent)
DELETE /v1/posts/{post_id}/like                    → 204
POST   /v1/posts/{post_id}/comments {text, reply_to?}  Idempotency-Key → 201 {comment_id}
GET    /v1/posts/{post_id}/comments?cursor=...

POST   /v1/users/{user_id}/follow                  → 200 {state: following|requested}
DELETE /v1/users/{user_id}/follow                  → 204

GET    /v1/search/typeahead?q=sel                  # users, hashtags, places
GET    /v1/stories/tray                            # high level
WS     /v1/realtime                                # DMs, typing, receipts (WebSocket)

Protocol choices: REST/JSON for the public mobile API (simple, cacheable, debuggable), gRPC between internal services (fast binary, deadlines, streaming), and a WebSocket for real-time DMs. The API Gateway handles authentication via JWTs and rate limiting in front of all of them.

7. Minutes 16–21: Data model

Pick the store per dataset based on its access pattern, and say why. A strong candidate names partition keys and explains how each query maps to exactly one partition (see databases, indexing).

7.1 User DB (PostgreSQL)

CREATE TABLE users (
  user_id        BIGINT PRIMARY KEY,          -- 64-bit time-sortable ID (see deep dive)
  username       VARCHAR(30) NOT NULL,
  full_name      VARCHAR(64),
  email          VARCHAR(255),
  password_hash  TEXT NOT NULL,               -- argon2/bcrypt
  bio            TEXT,
  avatar_key     TEXT,                        -- object-storage key, not the image
  is_private     BOOLEAN NOT NULL DEFAULT FALSE,
  created_at     TIMESTAMPTZ NOT NULL DEFAULT now()
);
-- Global uniqueness of username needs its own lookup table, sharded by username:
CREATE TABLE usernames (username VARCHAR(30) PRIMARY KEY, user_id BIGINT NOT NULL);

7.2 Posts, likes and comments (Cassandra CQL)

-- One post by ID (for hydration)
CREATE TABLE posts_by_id (
  post_id     bigint PRIMARY KEY,
  user_id     bigint,
  caption     text,
  media       list<frozen<media_ref>>,   -- rendition keys, width, height
  location_id bigint,
  status      text,                      -- PROCESSING | READY | REMOVED
  created_at  timestamp
);

-- Profile grid: all posts of a user, newest first (one partition per user, bucketed by month)
CREATE TABLE posts_by_user (
  user_id  bigint,
  bucket   int,                          -- e.g. 202610, keeps partitions bounded
  post_id  bigint,
  PRIMARY KEY ((user_id, bucket), post_id)
) WITH CLUSTERING ORDER BY (post_id DESC);

-- Who liked a post (idempotent: primary key = post + user)
CREATE TABLE likes_by_post (
  post_id  bigint,
  bucket   smallint,                     -- spreads mega-viral posts over N partitions
  user_id  bigint,
  liked_at timestamp,
  PRIMARY KEY ((post_id, bucket), user_id)
);

CREATE TABLE comments_by_post (
  post_id    bigint,
  comment_id bigint,                     -- time-sortable → natural ordering
  user_id    bigint,
  text       text,
  PRIMARY KEY (post_id, comment_id)
) WITH CLUSTERING ORDER BY (comment_id DESC);

7.3 Social graph and timelines

CREATE TABLE following (follower_id bigint, followee_id bigint, created_at timestamp,
                        PRIMARY KEY (follower_id, followee_id));
CREATE TABLE followers (followee_id bigint, follower_id bigint, created_at timestamp,
                        PRIMARY KEY (followee_id, follower_id));

# Redis
timeline:{user_id}          ZSET  score = created_at (or rank), member = post_id   (cap 500)
like_count:{post_id}:{n}    STRING counter shards, summed on read
post:{post_id}              HASH  cached hydrated post object (TTL hours)

8. Minutes 21–28: High-level design

Draw the boxes, then walk two requests through them: a write (post a photo) and a read (load the feed). That proves the diagram works.

More detailed hop-by-hop walkthroughs of all nine core flows are in End-to-End Request Flows.

9. Minutes 28–40: Deep dives

The interviewer will now pick, or let you pick, two or three areas. Lead with the one that's most central: the feed. Have all six below ready; in a real interview you'll cover two or three in depth and mention the rest.

9.1 Feed generation: fan-out on write, on read, or hybrid

 WRITE PATH (post.ready event)                 READ PATH (GET /feed for Bob)

 author has < ~1M followers?                   timeline:bob (Redis ZSET) ---------+
   YES -> PUSH: page through followers,          ~500 post IDs pushed earlier      |
          ZADD timeline:{f} ts post_id                                             +--> merge
          (skip inactive followers)             celebrities Bob follows (~0-50)    |    filter (blocked,
   NO  -> nothing (celebrity)                     -> PULL recent posts of each ----+    deleted, seen)
                                                     (hot, heavily cached)              rank -> top 20
                                                                                        hydrate -> JSON

Details a senior candidate adds: the threshold is a tunable (follower count and posting rate). Timelines are capped (~500 IDs), because nobody scrolls further and older content can be pulled. Timelines store IDs only, so edits and deletes don't need fan-out; hydration reads the current post object. Ranking happens at read time over the merged candidates. Unfollows are filtered at read time instead of being purged eagerly. Full treatment: news feed.

9.2 Media upload & processing

  Clients     API     Upload    Object    Cassandra   Kafka    Workers
            Gateway   Service   Storage
     |         |         |         |          |         |         |
     | 1 POST /media/uploads       |          |         |         |
     |-------->|         |         |          |         |         |
     |         | 2 route |         |          |         |         |
     |         |-------->|         |          |         |         |
     | 3 media_id + pre-signed URL |          |         |         |
     |<..................|         |          |         |         |
     | 4 PUT bytes       |         |          |         |         |
     |---------------------------->|          |         |         |
     | 5 POST /posts (via gateway) |          |         |         |
     |------------------>|         |          |         |         |
     |         |         | 6 INSERT post      |         |         |
     |         |         |------------------->|         |         |
     |         |         | 7 post.created     |         |         |
     |         |         |~~~~~~~~~~~~~~~~~~~~~~~~~~~~~>|         |
     | 8 201 {post_id}   |         |          |         |         |
     |<..................|         |          |         |         |
     |         |         |         |          |         | 9 resize, fan-out, index, notify
     |         |         |         |          |         |~~~~~~~~>|
     |         |         |         |          |         |         |

legend:  ----> synchronous call    ....> response    ~~~~> asynchronous event (Kafka)    -- local work

• Pre-signed URLs let clients upload directly to object storage. App servers never proxy bytes, and the URL is scoped to one key, size and content type and expires in minutes (see media upload).
• Resumable / multipart uploads for video: 5–8 MB chunks, so a dropped connection costs one chunk instead of the whole file.
• Client-side resize and compression before upload, which saves 80–90% of bytes for photos.
• Async processing via Kafka → media workers: renditions (150/320/640/1080 px, WebP/AVIF), video transcoding to HLS/DASH at several bitrates, thumbnails, EXIF stripping, moderation classifiers and perceptual-hash matching. Workers are idempotent, with a dead-letter queue for poison files (see media processing).
• Content-addressed, versioned keys (p/{media_id}/{hash}_1080.webp) let the CDN cache with max-age=1 year, immutable.
• Storage tiering: renditions of old, rarely viewed posts move to cheaper storage classes. Erasure coding gives ~1.4× overhead instead of 3× replication (see object storage). Public papers describe Facebook's Haystack and f4 systems doing exactly this kind of hot/warm split for photos.

9.3 Sharding & Instagram's ID scheme

 bit 63                                   23 22               10 9              0
    +--------------------------------------+-------------------+----------------+
    |  41 bits: milliseconds since a       |  13 bits: logical |  10 bits:      |
    |  custom epoch  (~69 years of range)  |  shard ID (8,192) |  sequence      |
    +--------------------------------------+-------------------+----------------+
                                                                (1,024 IDs per ms per shard)

 id = (now_ms - EPOCH) << 23  |  shard_id << 10  |  (seq % 1024)

 example: (500,000,000,000 << 23) | (1341 << 10) | 7  =  4,194,304,000,001,373,191
          → created 500 billion ms (~15.8 years) after the epoch, lives on logical shard 1341

-- One schema per logical shard; this function is created in each schema (shard 1341 shown)
CREATE SEQUENCE shard_1341.id_seq;

CREATE OR REPLACE FUNCTION shard_1341.next_id(OUT result bigint) AS $$
DECLARE
  our_epoch bigint := 1293840000000;          -- 2011-01-01T00:00:00Z in ms
  shard_id  int    := 1341;
  seq_id    bigint;
  now_ms    bigint;
BEGIN
  SELECT nextval('shard_1341.id_seq') % 1024 INTO seq_id;
  now_ms := floor(extract(epoch FROM clock_timestamp()) * 1000);
  result := ((now_ms - our_epoch) << 23) | (shard_id << 10) | seq_id;
END;
$$ LANGUAGE plpgsql;

• Logical vs physical shards: create thousands of logical shards (PostgreSQL schemas) up front, and map many of them onto each physical server. To scale, move whole logical shards to new machines. Nothing needs re-hashing, only a mapping-table update (see sharding).
• Shard key = user_id for users and their posts. A post's ID embeds its shard, so given any post ID you can find its shard without a lookup.
• Hot shards (one shard holding several celebrities) are handled by moving logical shards and by the caching and hot-key techniques below.
• Alternatives: Twitter's Snowflake (timestamp + machine ID + sequence, generated by a service), UUIDv4 (random, 128-bit, not sortable, poor index locality), UUIDv7/ULID (sortable 128-bit), and DB auto-increment (needs a central coordinator). Compared in ID generation.
• Cassandra tables use consistent hashing with virtual nodes on the partition key, so they need no manual shard map.

9.4 Caching strategy

Three issues to name before the interviewer does. First, cache stampede: when a hot key expires, thousands of requests miss at once. Fix it with request coalescing, a lock or lease so one request refills, and early probabilistic refresh. Second, invalidation races: delete the cache entry rather than updating it, and use versioning or leases (Facebook's Memcache paper describes leases for exactly this). Third, cold start after a cache node dies: warm it gradually and have consistent-hashed clients spread the misses. See caching.

9.5 The celebrity / hot-key problem

Hot keys are a recurring theme across caching, likes & counters, sharding and CDN. The general toolkit is replicate, split, batch, cache locally, and smooth over time.

9.6 Direct messages

• Transport: persistent WebSocket (or MQTT) connections terminated on a fleet of connection servers. A presence registry in Redis maps user_id → connection host with a heartbeat TTL. HTTP polling would waste battery and server capacity. See direct messaging.
• Ordering: a per-thread monotonically increasing sequence number assigned by the DM service. There's no global ordering, since conversations are independent.
• Storage: a Messages table partitioned by thread_id and clustered by seq. One conversation is one partition; very long conversations are bucketed by time.
• Delivery: persist first, then ack the sender. If the recipient is online, push over their socket; if offline, send an event to the Notification Service and APNs/FCM. On reconnect the client syncs after_seq = N. Client-generated client_msg_ids dedupe retries.
• Receipts: sent (server persisted), delivered (recipient device acked), read (recipient opened the thread). These are small, idempotent state updates.
• Group chats: fan out to members on send (small groups) and cap group size. End-to-end encryption changes the server's role to storing ciphertext blobs.

10. Minutes 40–43: Bottlenecks & trade-offs

Related lessons: resilience patterns, multi-region & DR, observability, core principles.

11. Minutes 43–45: Wrap-up

12. How Instagram actually does it (public information)

13. Evaluation rubric: junior vs senior vs staff

Interviewers typically score communication, requirements, high-level design, deep dives, trade-offs and operational thinking. Here is what each level tends to look like on this exact question.

14. Trade-offs & common mistakes

Common mistakes candidates make

• Jumping into boxes before scoping. You'll design the wrong system, or all of it shallowly.
• Estimation without conclusions. Numbers are only useful if you say what they imply ("~150k QPS → must precompute and cache").
• Media through app servers, or blobs in the database. Use pre-signed uploads, object storage and a CDN.
• Pure fan-out on write with no celebrity handling, or pure pull with no answer for read latency.
• "Just add a cache" without saying what's cached, the pattern, the invalidation and the hot-key behaviour.
• A single SQL database for everything with no sharding plan, or NoSQL for everything without reasons.
• Ignoring failure: no timeouts, retries, idempotency or degradation story.
• Sync calls for async work, like resizing images or notifying followers inside the request.
• Monologuing. Not checking in with the interviewer, missing their hints, running out of time before the deep dive.
• Over-engineering things that weren't asked for, like a custom consensus protocol or blockchain, while the feed is still undesigned.

15. How the design changes for similar products

16. Real-world technologies

17. Interview corner: follow-up questions

These are the follow-ups interviewers use to probe depth after the main design. Try answering each before opening it.

18. Check your understanding

Related lessons

• How to approach a system design problem: the framework this script follows
• Requirements and capacity estimation: minutes 0–12 in depth
• API design: cursors, idempotency keys, protocols
• News feed: the main deep dive
• ID generation and sharding: the ID scheme and logical shards
• Caching and likes & counters: hot keys and counters
• Media upload and media processing: the media deep dive
• Direct messaging: the DM deep dive
• End-to-end request flows: every flow traced hop by hop
• Glossary: every term in one place