How Would You Design Instagram?
Learn how to design Instagram — CDN-backed media storage, sharded metadata, feed fan-out, and approximate like counters.
Expected Interview Answer
Instagram is designed around three separable concerns — durable object storage for photos and videos behind a CDN, a metadata service backed by a sharded database for posts, likes and comments, and a fan-out feed pipeline similar to a text feed but with media references instead of raw bytes flowing through it.
When a user uploads a photo, the raw file is written to blob storage (like S3) and multiple resized renditions are generated asynchronously, then served through a CDN so repeat reads never hit origin storage. Post metadata — caption, owner, timestamp, like/comment counts — lives in a horizontally sharded database, typically sharded by user id or post id so a single user’s history stays on one shard for cheap range queries. The feed itself reuses the same fan-out-on-write with celebrity fan-out-on-read pattern used for any social feed, except each timeline entry stores just a post id and thumbnail reference; the actual media bytes are fetched from the CDN by the client. Counters like likes are handled with an approximate, eventually-consistent counter service rather than a strict read of every like row, since exact real-time precision is not worth the write contention at that scale.
- CDN-fronted object storage keeps media delivery fast and cheap regardless of read volume
- Sharded metadata storage isolates a user’s post history for efficient profile-grid queries
- Reusing the feed fan-out pattern avoids reinventing timeline delivery for a media-heavy feed
- Approximate counters avoid write contention on hot posts with millions of likes
AI Mentor Explanation
Designing a photo-sharing platform is like a stadium that stores raw match footage in a huge archive vault, while every screen around the ground actually plays from a nearby local relay rather than pulling straight from the vault each time — that relay is the CDN. The scoreboard tracks who posted which highlight and how many claps it got in a lightweight ledger, separate from the heavy footage itself, mirroring how metadata is stored apart from media bytes. A viral six from a superstar batter is merged into fans’ personal highlight reels only when they check, just like celebrity fan-out on read. And the clap count shown live is an approximation updated in batches, not an exact tally recomputed on every clap.
Step-by-Step Explanation
Step 1
Upload and store media
The client uploads a photo/video to blob storage; a worker generates resized renditions and pushes them behind a CDN.
Step 2
Write metadata
Post metadata (owner, caption, timestamp) is written to a sharded database, typically sharded by user or post id.
Step 3
Fan out the reference
A lightweight post id and thumbnail reference is fanned out into followers’ timelines using the same hybrid write/read pattern as a text feed.
Step 4
Serve from CDN with approximate counters
Clients fetch media directly from the CDN edge, and like/comment counts are shown from an approximate, batched counter service.
What Interviewer Expects
- Separates media storage/CDN delivery from lightweight post metadata storage
- Explains sharding strategy for metadata (by user id or post id) and why
- Reuses/adapts the feed fan-out pattern rather than reinventing it for media
- Mentions approximate counters for likes/views to avoid write contention on hot posts
Common Mistakes
- Storing raw image/video bytes in the same database as post metadata
- Serving media directly from origin storage instead of a CDN
- Recomputing exact like counts on every read at massive scale
- Ignoring how celebrity accounts break naive per-follower fan-out for media posts too
Best Answer (HR Friendly)
“Instagram works by keeping the actual photo and video files in one specialized storage system fronted by a fast content delivery network, while a separate, lighter database just tracks who posted what and basic details like captions and like counts. When you open your feed, the app is mostly just looking up small references and pulling the real images from the nearest fast server, which is why it feels instant even with huge amounts of media.”
Code Example
def upload_post(user_id, image_bytes, caption):
blob_key = blob_storage.put(image_bytes) # original stored durably
# async job generates thumbnail/medium/large renditions
resize_queue.enqueue(blob_key)
post_id = metadata_db.insert(
shard_key=user_id,
owner_id=user_id,
blob_key=blob_key,
caption=caption,
like_count=0,
)
fanout_service.publish(user_id, post_id, blob_key)
return post_id
def get_cdn_url(blob_key, size="medium"):
# CDN serves cached renditions; origin is only hit on a cold cache miss
return f"https://cdn.example.com/{blob_key}/{size}.jpg"
def increment_like(post_id):
# approximate counter service batches increments instead of a
# strict row-level UPDATE on every single like
counter_service.incr(f"likes:{post_id}")Follow-up Questions
- How would you shard the metadata database to avoid hot shards for viral posts?
- How would you generate and store multiple image resolutions efficiently?
- How do you keep an approximate like counter eventually consistent with the true count?
- How would you handle Stories, which expire after 24 hours, differently from permanent posts?
MCQ Practice
1. Why does Instagram-style design separate media storage from post metadata storage?
Media bytes are large and best served from a CDN-backed blob store, while metadata is small, structured and needs indexed queries, so they use different storage systems.
2. Why use an approximate counter service for likes on very popular posts?
A viral post receiving thousands of likes per second would cause massive write contention on a single row; batched, approximate counters avoid that bottleneck.
3. What does the CDN primarily solve for a photo-sharing platform?
A CDN caches media at edge locations near users so repeated reads never hit origin storage, dramatically reducing latency and origin load.
Flash Cards
Why separate media storage from metadata? — Media is large and read-heavy (needs CDN); metadata is small and query-heavy (needs indexed DB).
How does a photo feed reuse text-feed design? — It uses the same hybrid fan-out-on-write/read pattern, storing only post id + thumbnail reference per timeline entry.
Why approximate like counters? — To avoid write contention on hot posts by batching increments instead of updating one row per like.
What triggers a CDN cache miss? — A request for media not yet cached at that edge location, which then falls back to origin blob storage.