Frontend System Design Interview Walkthrough: Build the Instagram Feed

THE CONCEPTS

The mental models, one by one

1. 01

   Requirements & the Traffic Math

   Ask before assuming: web or mobile? Images only or video? Likes and comments in scope? You're judged on your questions, especially early.

   Then quantify: 1M daily actives, each posting once and consuming ~100 posts — a 1:100 read-to-write ratio you'll exploit later. 70% online in a two-hour evening peak ≈ 10K requests/second. 1MB per image means throughput is a problem too.

   Read/write ratioBack-of-envelopePeak traffic
2. 02

   The Minimum Viable System

   Web app → feed service → NoSQL database for post metadata, with images in blob storage (the service returns URLs, never the bytes).

   Get this on the board before optimizing anything. The interview goal isn't solving — it's showing how you think and keeping the interviewer bought in with open-ended questions.

   Blob storageNoSQLInterviewer buy-in
3. 03

   Scaling: CDNs and the Read/Write Split

   Two CDNs first: one for the app's static assets, one for images. That also removes single points of failure.

   Then split the feed service into a read service and a write service — the 1:100 ratio means the read side takes the beating, so scale it horizontally behind a load balancer while writes stay simple.

   Add a Redis cache for hot data: viral posts don't change, so serve their metadata from memory. Thumbnail generation goes async — a serverless job after upload.

   Read/write splitLoad balancingRedisAsync jobs
4. 04

   Defending the Database Choice

   NoSQL here — but the why matters more than the pick: posts have simple relationships (post → user, little else) and document stores scale reads with less ceremony.

   Complex relational data would flip the answer to Postgres or MySQL. Shape of the data first, scalability second.

   NoSQL vs SQLData shape
5. 05

   List Virtualization in the Client

   Infinite scroll means unbounded DOM growth — mobile browsers choke long before users stop scrolling.

   Unmount posts outside the viewport, keep placeholders so the scrollbar stays honest, and use IntersectionObserver (or a library like react-virtualized) as the sliding window.

   WindowingIntersectionObserverDOM pressure
6. 06

   Cursor-Based Pagination

   Page-number pagination breaks on a live feed: new posts push content down and page 6 repeats page 5.

   Cursor-based pagination anchors on a post id — "give me the next five after this one" — so fresh inserts can't shift what the user sees. Pair the cursor fetch with the same IntersectionObserver driving the virtualization.

   Cursor paginationFeed consistency
7. 07

   Knowing When NOT to SSR

   The feed is state-heavy and instantly scrolled — pre-rendering it buys almost nothing. The chrome around the feed? Pre-render away.

   Saying no to SSR with a reason is a stronger senior signal than reaching for it. Same for the five interview mistakes: assuming too much, losing the interviewer, running out of things to say, talking outside your depth, and drowning in implementation details.

   SSR trade-offsInterview mistakes