Instagram — system-design tick-by-tick request flow
A single-file in-browser walkthrough of what actually happens inside an Instagram-shaped backend when you open the app, post a photo, run a search, fetch a static image, or get a push notification. Every operation — DNS lookup, TLS handshake, cache hit/miss, shard lookup, blob upload, fanout job — is animated one step per 0.5 s tick with a live event log on the left so you can see exactly which subsystem is doing what.
The architecture is the canonical interview-grade one from the GeeksForGeeks diagram: DNS, Client, Load Balancer, two API gateways, read/write App Servers, a Redis/Memcached cache with Shard Manager in front of sharded Metadata DBs, a Notification Service + queue, a Search Aggregator over Elastic Search, a CDN backed by Blob Storage, a Video/Image Processing Service with workers, and a Feed Generation Service draining a fanout queue.
Scenarios
The sim cycles through five real flows. Click a tab on the toolbar to jump.
| Scenario | What it walks |
|---|---|
| App launch | Cold start: DNS query → resolver answer → TLS to LB → API Gateway routing GET to App Server (read) → cache MISS → Shard Manager lookup → Metadata DB → cache populate → JSON back through the gateway → client renders feed. |
| Photo upload | Multipart POST → LB → API Gateway 2 → App Server (write) → enqueue on Video Processing Queue → worker picks up → transcode + thumbnail → PUT to Blob Storage → enqueue Feed Generation Queue → Feed Gen Service writes denormalised feed entries to 1 200 followers + drops PushNotif messages. |
| Search | GET /search?q=… → App Server (read) → Search Results Aggregator → Elastic Search index (own LRU cache) → 40 doc IDs → hydrate metadata via mget → merged result back to client. |
| CDN fetch | Pure static-content path: GET image URL hits CDN POP directly. On miss the CDN pulls from Blob Storage; on hit the request never touches the app servers. |
| Push notification | Feed Generation Service drops a fanout job in the Notification Queue → Notification Service drains, signs APNs/FCM JWT, pushes to the user’s device (modelled as a direct edge from notif service to client). |
How to read it
- Particle colour maps to the kind of traffic: blue = read, pink/red = write, cyan = search, violet = CDN/static, amber = notification, green = queue work between services.
- Glowing node border = that node just received or emitted a message in the last tick.
- Solid arrow with arrowhead = the message currently in flight; the faint dashed lines behind everything are the static topology.
- Event log on the left is the source of truth — every tick adds one
line (
[t12] 7. cache → shard · shard manager: lookup user 42). Newest on top; ~200 entries retained. - Hover any node on the canvas for an explanation of what that subsystem actually is in a real Instagram-like deployment (Rails, Postgres, S3, Redis, Kafka, Sidekiq, Akamai, APNs, Elastic Search, etc.).
Controls
| Key / mouse | Action |
|---|---|
space | Run / pause |
s | Step one tick (0.5 s simulated) |
shift+s | Step ×10 |
r | Reset |
| Scenario tabs | Jump to that scenario (launch / upload / search / cdn / push) |
| Speed slider | Wall-clock tempo of the run loop |
| hover any node | Live explanation tooltip |
What’s “precise” about it
- Tick granularity — every action takes one or two ticks (0.5 – 1 s). That’s slow enough to read the event log live, fast enough that a full scenario cycles in ~10 s.
- Sharded write path — uploads enter a Video Processing Queue first (durability + decoupling) then a Feed Generation Queue (fanout). The two queues are separate so a slow transcode can’t starve the feed writer.
- Read/write split at the API gateway tier — the simulator routes GET to API Gateway 1 / App Server (read) and POST/PUT/DELETE to API Gateway 2 / App Server (write). Same physical fleet in many deployments, but logically separated so reads can hot-cache and writes can durable- queue.
- CDN bypasses everything — image/video bytes don’t go through the LB or the app servers. CDN cache hit means just CDN ↔ client; miss means CDN ↔ Blob Storage.
- Push fanout is asynchronous — Feed Gen Service writes the feed AND drops fanout push jobs. The Notification Service drains the queue at a rate that doesn’t trigger APNs/FCM throttling.
Reference
The diagram is the GeeksForGeeks “Instagram System Design” reference image. This sim animates that exact topology end-to-end with synthetic but realistic traffic.