Instagram Social Media – System Design Interview Preparation

Practice designing Instagram. Cover news feed, image/video storage, stories, direct messaging, and content delivery at scale.

This is a full mock interview round, not a written solution to read through. The AI interviewer poses the Instagram design problem, pushes back on your choices, and asks the follow-up questions a real interviewer would: how the system behaves as traffic grows, where the bottlenecks move, which consistency guarantees you are trading away, and what happens when a component fails. You get structured feedback and a score on requirement gathering, high level architecture, data modelling, scalability and communication at the end of every attempt.

Designing Instagram is a recurring question in High Level Design (HLD) rounds at Google, Amazon, Meta, Microsoft, Netflix and Uber, and at high-growth product companies hiring SDE-2 and above. Working through it out loud - repeatedly, under time pressure - is what separates candidates who know the components from candidates who can defend a design.

What this question is really testing

The same fan-out question as a timeline, plus a media pipeline where the bytes dwarf the metadata by four orders of magnitude.

Scale to establish before drawing anything

500M daily users, 100M photos a day - about 1,200 uploads a second, with reads 100x that.
An original photo is a few MB; five rendered variants per upload means storage grows faster than the upload count suggests.
Metadata per post is under 1 KB, so the feed index and the media store have completely different shapes.

Core components

Upload service – Accepts the original to object storage and enqueues processing. Returns before processing finishes.
Media processing pipeline – Generates thumbnails and resolution variants asynchronously.
CDN – Serves every byte a user sees. If images come from your origin, the design is wrong.
Feed service – Hybrid fan-out over the follow graph, same shape as a timeline.
Metadata store – Posts, captions, likes, comments - small rows, high read volume.

Trade-offs to defend

Pre-generate variants versus resize on demand – Pre-generating costs storage for sizes nobody requests; on-demand costs latency on the first request and needs its own cache.
Like counts: exact versus approximate – Exact counts on a viral post are a write hotspot. Approximate counts with periodic reconciliation is the standard answer.
Stories as a separate system – A 24-hour TTL changes the storage decision completely and is worth separating rather than bolting onto posts.

Follow-up questions to expect

Upload succeeds but processing fails. What does the user see, and what retries?
A post gets 10M likes in an hour. Where is the hotspot and how do you shard around it?
Add a ranked feed. What does that do to your fan-out, and can you still cache a list of ids?