Instagram combines two architecturally distinct systems: a media processing pipeline (like YouTube, but for photos and short videos) and a social feed system (like Twitter, but with ML-ranked content rather than chronological). The interview tests whether you can reason about both simultaneously and understand where they interact.
Instagram appears in interviews at the senior and staff level because it requires holding multiple system concerns in mind at once. The key skills being probed:
Media pipeline design. Unlike Twitter where the content is text, Instagram's content is predominantly photos and videos. Every post triggers a media processing pipeline: upload, resize to multiple dimensions, deduplication, CDN distribution, perceptual hash generation. This pipeline is CPU-bound, asynchronous, and must not block the post creation response. The interviewer is checking that you separate the blob processing concern from the metadata concern and handle them via different system paths.
Read-heavy CDN architecture. Instagram is one of the highest-traffic CDN users in the world. At 1 billion users with multiple photo/video loads per session, the volume of media reads dwarfs the write volume by orders of magnitude. The interviewer is checking that you lead with CDN design for the read path and do not design a system where media reads hit origin servers.
Ranked feed vs chronological. Instagram's home feed is not chronological — it is ML-ranked. This changes the architecture: you cannot simply pre-compute a timeline and serve it. You need candidate generation (recent posts from followed accounts), ranking inference (predicting engagement for this user on each post), and result caching (ranking is expensive; you don't re-rank on every scroll). The interviewer is checking whether you mention the ML ranking layer and understand its compute implications.
The social graph at scale. 1 billion users with an average of 300 follows each means 300 billion edges in the social graph. Storing and traversing this graph efficiently is a distinct challenge. The edges must be accessible for feed generation (who does user X follow?) and for follow recommendations. The interviewer is checking that you reason about graph storage and traversal separately from post storage.
Users and posts. 1 billion DAU, each opening the app 3 times per day, each session loading 20 photos → 60 billion photo loads per day. 100 million new photos uploaded per day. Write-to-read ratio: 1:600. This is one of the most read-heavy workloads in any system design question.
Upload bandwidth. Average photo: 3 MB before compression, ~500 KB after. At 100 million uploads/day: 100M × 500 KB / 86,400 = ~580 GB/day of processed photo storage added daily. After CDN replication across PoPs, effective storage is 5–10× higher.
Photo reads. 60 billion loads/day / 86,400 seconds = ~694,000 photo requests per second at average, peaking at 3–5M/sec. These must be served from CDN — serving 694K RPS from origin servers would require an impossibly large fleet.
Photo dimensions. Each uploaded photo is resized to approximately 5 formats: thumbnail (150×150), grid (612×612), feed (1080×1080), full-res, Story (1080×1920). Storage amplification: ~5×. 580 GB/day raw × 5 = 2.9 TB/day new media storage.
Social graph edges. 1 billion users × 300 follows average = 300 billion edges. Each edge: (follower_id, following_id) = 16 bytes. 300B × 16 bytes = 4.8 TB just for edge storage. This fits in a sharded relational database (or graph database) with appropriate indexes, but traversal at scale (fetching all accounts a user follows) requires caching the hot edges in Redis.
Upload path: direct-to-CDN edge. The client uploads the raw photo bytes directly to the nearest CDN edge node (bypassing application servers entirely for the blob). This reduces upload latency (shorter path to storage) and removes the blob bytes from application server bandwidth. The application server receives only the post metadata (caption, location, hashtags) and an upload confirmation, not the bytes. After upload, a job is published to a processing queue.
Photo processing pipeline. A pool of processing workers consumes the queue. Each job: decode raw image → resize to 5 dimensions → compress each format → compute perceptual hash (pHash) for dedup → write all versions to object storage → update CDN manifest → mark post as available in metadata DB. The post is not visible to followers until processing completes. Worker failures are safe because the job is re-queued; the idempotency key (original upload hash) prevents duplicate processing.
Object storage + CDN layering. Processed photos are stored in object storage (S3-compatible). The CDN is configured to origin-fetch from object storage on a miss. Popular photos are cached at all major PoPs; less-popular photos are cached lazily on first request. Content-addressed URLs (using a hash of the photo bytes) enable aggressive CDN TTLs (years) — the URL changes only when the content changes. This is the correct CDN strategy for immutable media.
Feed generation: candidate + rank. Feed generation has two stages. Stage 1 — candidate generation: fetch the 500 most recent post IDs from accounts the user follows. This is a read from the social graph (Redis-cached follow list) and a read from each followed account's post index (Cassandra, partitioned by user_id). Stage 2 — ranking: a lightweight ML model scores each of the 500 candidates for predicted engagement from this specific user. The top 50 are returned as the feed. The ranking model is deployed as a low-latency inference service (target: under 100ms for 500 candidates).
Feed caching. Ranking 500 candidates on every scroll is expensive. The ranked feed is cached per user with a short TTL (5–10 minutes). New posts published during the TTL window are injected into the cached feed (a hybrid push model for accounts the user interacts with frequently). Full re-ranking happens on TTL expiry or on explicit pull-to-refresh.
Social graph in Redis. The hot social graph edges (who follows whom, for users who posted recently) are cached in Redis as sorted sets. The score is the timestamp of the most recent interaction (like, comment, DM) — allowing the feed system to weight recently-interacted accounts more heavily in candidate selection. Full graph traversal for cold users goes to PostgreSQL.
Explore page: embedding + ANN search. The Explore page requires discovering content the user hasn't seen and doesn't follow. Each photo is embedded into a 256-dimension vector by a vision model at upload time. At query time, the user's interest profile (derived from their engagement history) is compared against the photo embeddings using approximate nearest neighbour search (Faiss, Annoy, or Pinecone). The top-k candidates are re-ranked by recency and engagement rate before display.
Load the Social Feed blueprint in SysSimulator — it closely models Instagram's feed generation architecture. Extend it mentally with a media pipeline worker in front of the post write path.
Set traffic to 50,000 RPS to simulate a busy feed scroll session. Observe CDN hit rate — it should be 95%+. The metadata service (post metadata lookups) should handle a small fraction of total traffic. Most load is absorbed by the CDN before reaching any application layer.
Inject a CDN edge failure. Watch: photo load requests that were hitting the edge now fall back to origin. Origin request rate spikes. P99 latency for affected users climbs from ~50ms to 500ms+ as requests travel further. The feed metadata is unaffected — only photo loading degrades.
Separately, inject a cache stampede on the feed cache. Watch: all feed generation requests hit the ranking service simultaneously, the ranking service queue depth climbs, and feed load times increase. This is what happens when a large cohort of users opens the app simultaneously after a TTL expiry (e.g., morning commute hour).
"I'll inject a photo processing queue backup — simulating a spike in uploads that outpaces the worker pool capacity."
"[inject] Upload rate stays constant — photos are being accepted by the ingestion service and written to object storage raw. But the processing queue depth is climbing because workers can't keep up. Photos uploaded in the last 3 minutes are not yet available on followers' feeds — they're still pending resize and CDN distribution."
"The blast radius: new posts are delayed, not lost. Users who just posted see their photo as 'processing' for longer than normal. No data is at risk — the raw upload is safely in object storage. Existing posts and feeds are completely unaffected."
"Mitigation: autoscale the worker pool based on queue depth. The metric to alert on is queue depth, not worker CPU — workers can be CPU-idle while queue depth climbs if the bottleneck is in a downstream dependency (e.g., the resize service). With autoscaling triggered at queue depth > 1,000 jobs, new workers spin up within 60 seconds and drain the backlog within 3–5 minutes."
"How do you handle the fan-out problem for celebrities with 100 million followers?" Same hybrid as Twitter: for regular users, fan-out on write (push new posts into followers' feed caches). For accounts with > ~500K followers, fan-out on read (inject at feed load time from a separate "celebrity posts" data structure). The threshold is lower than Twitter's because Instagram's feed is ML-ranked — the ranking model can incorporate celebrity posts without pre-pushing them everywhere.
"How do you prevent duplicate photos?" Perceptual hashing (pHash) generates a compact fingerprint of the image content that is robust to minor edits (resizing, slight colour adjustments). On upload, compute the pHash and check against an index. If a matching pHash exists, the upload is flagged as a potential duplicate. This is used for copyright enforcement (Content ID equivalent) and spam prevention, not to block uploads by default.
"How do you handle Stories (24-hour expiry)?" Stories are a separate content type with a different lifecycle. They expire after 24 hours. Storage approach: write Stories to a separate object storage bucket with a 24-hour TTL. After expiry, soft-delete the database record and let the storage bucket lifecycle policy delete the blobs. CDN TTLs for Story media are set to 24 hours. This ensures expired Stories stop being served without requiring active deletion from CDN edge caches.
How is Instagram different from Twitter architecturally?
The media pipeline: every Instagram post includes a photo/video requiring resize, compression, CDN distribution. This CPU-bound async pipeline sits alongside the Twitter-style social graph system. Additionally, Instagram's feed is ML-ranked, requiring candidate generation + ranking inference, versus Twitter's simpler fan-out-on-write timeline.
How does Instagram generate the home feed?
Two stages: candidate generation (fetch ~500 recent posts from followed accounts via social graph) and ranking (ML model scores each for predicted engagement). Top 50 returned. Ranked result cached per user for 5–10 minutes to avoid repeated expensive inference.
How does Instagram handle photo uploads at scale?
Direct-to-CDN upload bypasses application servers for blob bytes. An async processing queue resizes to 5 dimensions, compresses, and distributes to CDN. Post is not visible until processing completes. Worker failures are safe — jobs re-queue idempotently.
How does Instagram's Explore page work?
Photos are embedded into vectors at upload time. User interest profile is compared against the embedding corpus via ANN search (Faiss/Pinecone). Top-k candidates re-ranked by recency and engagement rate. Entirely separate from the home feed candidate generation path.
What database does Instagram use?
PostgreSQL (sharded) for user data and post metadata, Cassandra for activity feeds and comments, Redis for social graph hot edges and feed caches, object storage (S3-compatible) for media blobs.
Run this in SysSimulator → Browse all blueprints
Next: Design Google Drive →