Skip to main content

Design Instagram

Instagram shares its feed-and-follow shape with Design Twitter — the fan-out-on-write-vs-read tradeoff from that lesson applies here too, and is worth mentioning rather than re-deriving. What makes this problem genuinely different is what's actually being posted: large binary media (photos and videos) instead of short text, which turns storage and delivery — not feed assembly — into the interesting new problem. Following the framework from How to Answer a System Design Interview Question.

1. Requirements​

Functional:

  • Users upload photos/videos, which appear in their followers' feeds.
  • Media must load quickly regardless of the viewer's location.

Non-functional:

  • Media files are large (megabytes, not bytes) — this changes the storage answer from the earlier text-based problems entirely.
  • Upload can tolerate some latency (a short processing delay is acceptable); viewing an already-posted photo cannot — that's the constant, repeated, latency-sensitive path.

Scale estimate: assume 100M photos/day uploaded, averaging 2MB each (~200TB/day of new media) and a read-to-write ratio in the thousands to one, since a single popular photo can be viewed by a huge fraction of its poster's followers repeatedly.

2. API Design​

POST /media           multipart upload  returns: { media_id, status: processing }
GET  /media/{media_id} returns: { url, ready: bool }
GET  /feed/{user_id}   returns: [{ media_id, author_id, url, posted_at }]

3. Data Model​

Following the same metadata/content split as Design Pastebin, scaled up:

media (metadata — relational database)
  media_id     VARCHAR PRIMARY KEY
  author_id    VARCHAR
  storage_key  VARCHAR    -- pointer into object storage
  posted_at    TIMESTAMP

(actual image/video bytes — object storage)
  key: storage_key -> raw media file (+ generated thumbnail sizes)

4. High-Level Design​

System Design Lab

Every photo view is served through a CDN rather than hitting object storage directly — exactly the caching-applied-to-geography case that lesson describes, and the single highest-leverage piece of this design given how lopsided the read/write ratio is: the overwhelming majority of requests for a given photo never need to reach the origin at all once it's cached at the edge.

5. Deep Dive: processing uploads asynchronously​

A photo isn't stored exactly as uploaded — it typically needs to be re-encoded into several thumbnail sizes (feed preview, full view, profile grid) before it's ready to serve efficiently to different contexts. Doing this synchronously, on the upload request itself, would make every upload wait on potentially several seconds of image processing — a poor fit given the requirement that uploads can tolerate some latency but shouldn't need to block on it unnecessarily. The better fit is Event-Driven Architecture: the upload endpoint stores the original file and immediately returns processing, then publishes an event that a separate resizing service consumes asynchronously — via a message queue — generating each thumbnail size and updating the media record to ready once done. The client polls or receives a push once processing completes, rather than the uploader's own request thread blocking on all of it.

6. Deep Dive: assembling a feed of media, not text​

Design Twitter's fan-out-on-write mechanism carries over almost unchanged for feed assembly: posting a photo still means pushing its media_id into every follower's precomputed timeline, exactly the way a tweet ID gets pushed there. What's genuinely different is how heavy each pushed entry is allowed to be.

A feed entry here stays deliberately thin — just media_id, storage_key, and posted_at — never the media bytes themselves, and not even a pre-computed signed URL. Precomputing full media details into millions of followers' timelines on every post would multiply this design's already-large storage cost by the same fan-out factor that made Twitter's celebrity problem painful, except with megabytes per entry instead of bytes. Keeping the pushed entry to a bare pointer means the fan-out write stays cheap regardless of how large the underlying photo is — the expensive part, actually serving the media, happens once per view through the CDN, not once per follower at post time:

System Design Lab

Splitting the design this way — cheap metadata fan-out on the write path, expensive bytes served lazily and independently on the read path — is what lets this system scale its feed-assembly cost the same way Twitter does, without paying Twitter's fan-out cost per megabyte instead of per byte.

7. Tradeoffs​

Processing asynchronously means a photo isn't immediately available in every size right after upload — there's a real, if brief, window where it's uploaded but not yet fully processed. That's an acceptable tradeoff given the stated requirement (uploads can tolerate latency); the alternative — synchronous processing — would directly violate the goal of a fast, responsive upload experience by tying the client's wait time to however long image processing happens to take.

The thumbnail generation itself carries its own tradeoff, worth naming explicitly: generating every size (feed preview, full view, profile grid) up front at upload time means storage cost per photo is multiplied by however many sizes are pre-generated, most of which may never actually be requested for a given photo — versus generating a size on demand at first request and caching that result, which keeps storage proportional to what's actually viewed but adds latency to whichever request happens to be the first one to need a size that doesn't exist yet.

Asynchronous media processing vs. synchronous processing on upload: pros and cons​

Pros

  • Upload requests return quickly regardless of how long processing takes
  • Processing work can be scaled and retried independently of the upload path
  • A processing failure doesn't fail the upload itself — it can be retried separately

Cons

  • A brief window exists where a photo is uploaded but not yet fully processed
  • Requires the client to poll or receive a push for processing completion
  • Adds a queue and a separate processing service as new infrastructure to run

Further Reading​

Share this lesson

Saved locally in your browser — visible in the sidebar as you go.