Design Instagram — Cheat Sheet

Instagram is two systems in one: a media pipeline that stores and delivers photos/videos at massive scale, and a feed system that assembles each user’s personalized home timeline. The defining decision is how to build the feed — fan-out-on-write (precompute timelines) vs. fan-out-on-read (assemble on request) — and a hybrid that handles celebrities with millions of followers.

• ✓Upload photos and videos with captions
• ✓Follow / unfollow other users
• ✓Home feed — recent posts from people you follow, newest first
• ✓Like and comment on posts
• ✓View a user’s profile grid and explore/discover content
• ✓500M+ users, extremely read-heavy (feed loads ≫ posts)

• ✓Users: 500M total, ~300M daily active
• ✓Posts / day: ~100M → ~1,150 writes/sec
• ✓Feed reads: billions/day → ~100k+ reads/sec
• ✓Avg media size: ~1.5 MB (post-compression)
• ✓Read:write ratio: ~100:1 — cache everything hot

• ✓Client + CDN — The app loads feed metadata from the API and pulls the actual images/videos from a CDN edge close to the user. The CDN serves the vast majority of media bytes, keeping origin load and latency low.
• ✓API Gateway / Load Balancer — TLS, auth, rate limiting, and routing to the Media, Feed, and Graph services. Stateless and horizontally scaled.
• ✓Media Service + Object Store (S3) — Handles uploads, stores originals in an object store (S3), and kicks off an async transcoding/thumbnail pipeline. Generated renditions are pushed to the CDN. Media bytes never live in the database.
• ✓Post & Graph Store (NoSQL — Cassandra) — Posts, the follower/following graph, likes, and comments live in a wide-column NoSQL store (Cassandra) partitioned for high write throughput and horizontal scale. The access pattern is key-based and append-heavy.
• ✓Feed Service (fan-out) — Builds home timelines. On a new post it fans out the post id into followers’ precomputed timeline lists (fan-out-on-write); for celebrities it switches to fan-out-on-read to avoid writing to 100M lists.
• ✓Timeline Cache (Redis) — Stores each active user’s materialized timeline (a list of post ids) in Redis so a feed load is a single fast cache read, not a scatter-gather across the graph.

• ✓Feed generation strategy → Hybrid fan-out (push for most, pull for celebrities): Pure push explodes on million-follower accounts; pure pull makes every read a slow scatter-gather. The hybrid keeps the 100:1 read case fast while taming celebrity fan-out.
• ✓Where does media live? → Object store (S3) + CDN, never the DB: Media is the bulk of the bytes and is read enormously. An object store gives durable cheap storage; a CDN gives low-latency global delivery and offloads the origin.
• ✓Posts & graph store: SQL vs. NoSQL → NoSQL wide-column (Cassandra): The workload is append-heavy, key-addressed, and huge, with no hot-path joins. Cassandra scales writes horizontally; a single relational master would bottleneck.
• ✓Feed consistency → Eventual consistency: Seeing a post a second or two late is fine; availability and latency matter far more. This freedom is exactly what lets the feed be aggressively cached and fanned out async.

• ✓Frame it as two systems: a media pipeline and a feed system — then go deep on the feed.
• ✓The fan-out-on-write vs. -on-read trade-off is the whole interview; land the hybrid and the celebrity problem.
• ✓Media → object store + CDN, DB holds only metadata/URLs. Same split as a file-storage system.
• ✓Justify NoSQL (Cassandra) by the access pattern: append-heavy, key-based, no hot-path joins.
• ✓Explain the timeline cache (Redis list of post ids) as what makes sub-200ms feeds possible.
• ✓Handle counts (likes/followers) with distributed counters or cached aggregates, not COUNT(*) per view.