Design Instagram — System Design Interview Practice

Interview prompt

Design a global Instagram-like photo and video sharing platform for uploads, profiles, follows, personalized feeds, stories, likes, comments, and discovery.

• Keep media bytes, metadata, social graph state, and feed projections in independently scalable systems.
• Use direct resumable uploads, asynchronous media processing, object storage, and a CDN for large assets.
• Choose a hybrid feed strategy that protects the system from celebrity fanout explosions.
• Explain privacy, moderation, deletion, story expiry, retries, and eventual consistency explicitly.

Requirements and scale assumptions

• Users upload photos and videos, edit captions, publish posts, and view profile timelines.
• Users follow or unfollow accounts and receive a personalized home feed.
• Users publish stories that expire after 24 hours and can like, comment on, or share content.
• Users search accounts and hashtags while enforcing private-account, block, moderation, and deletion rules.
• Media upload acknowledgement should not wait for transcoding or thumbnail generation.
• Target p95 below 200 ms for a cached feed page and below 2 seconds for ordinary media readiness.
• Feed reads should remain bounded even when a followed account has millions of followers.
• Retries, duplicate events, worker loss, cache loss, and regional degradation must be recoverable.
• 500 million daily active users, 100 million media uploads per day, and 10 million peak concurrent viewers.
• Most accounts have fewer than 1,000 followees, but a small creator set has tens of millions of followers.
• Each upload creates multiple image or video renditions and thumbnails stored with lifecycle policies.
• Stories have a 24-hour visibility window, while takedowns and privacy changes take effect immediately.

• Media upload rate: ~1.2K/s avg — 100M uploads per day before burst and retry headroom.
• Feed read latency: p95 <=200ms — Serve a cursor page from a bounded projection and cache.
• Media readiness: p95 <=2s — Required renditions become playable asynchronously after upload.
• Story lifetime: 24 hours — Expiry is enforced in reads and by cleanup workers.

Key entities

• MediaAssetasset_id, owner_id, object_key, checksum, renditions, state

  Store bytes in object storage and keep lifecycle and processing metadata in a database.

• PosteventId, globalInstagramLikePhotoId, eventType, version, occurredAt, payload

  The durable source record is separate from feed entries and counters.

• StorypolicyId, tenantId, scope, version, rules, updatedAt

  Expiry is a serving constraint, not a reason to rely only on a cache TTL.

• FollowEdgeglobalInstagramLikePhotoId, status, version, observedAt, freshness, updatedAt

  Maintain both follower and following access paths for fanout and profile queries.

• FeedEntry

  A rebuildable projection; celebrity posts can be merged during reads.

• Interaction

  At-least-once consumers deduplicate by event or actor-object key.

Data flow

1. 1. Reserve a resumable uploadThe client requests signed part URLs, uploads directly to object storage, and retries individual parts by checksum.
2. 2. Commit the content recordThe API validates ownership and policy, writes post or story metadata, and returns a durable identifier.
3. 3. Process media asynchronouslyWorkers scan, resize, transcode, and write rendition manifests; failed jobs retry through a dead-letter queue.
4. 4. Build the feed projectionPublication events fan out to ordinary followers, while high-follower authors are merged on read or through a hybrid shard.
5. 5. Serve and invalidate asynchronouslyFeed and story reads use cursors, cache, and CDN URLs while counters, notifications, analytics, expiry, and deletion consumers catch up independently.

Deep dives and trade-offs

• Hybrid feed fanoutPush ordinary-author posts into a bounded per-user inbox for fast reads. Pull celebrity posts at read time or write them to a small set of shards. Use a versioned cursor and deduplicate post IDs after merging candidates.
• Media processing and deliveryUse checksum-based multipart retries and immutable object keys. Generate a bounded rendition set and publish a manifest only after required outputs are ready. Use signed CDN URLs, short metadata caches, and purge events for deletion or moderation.
• Privacy, deletion, and expiryRecheck follow, block, private-account, moderation, and expiry state at read time. Tombstone source records before asynchronous projection and CDN cleanup. Run expiry sweeps as repair work even when story TTL notifications are delayed.
• Exactly-once user experienceMake post, follow, like, and comment commands idempotent with request IDs. Deduplicate at consumers because the stream is at-least-once. Return optimistic UI state with a server version so reconnects can reconcile safely.
• Push versus pull feedsUse hybrid fanout: push normal accounts and pull high-follower accounts. The threshold and merge logic add complexity and require lag monitoring.
• Strong versus eventual countersMake the actor-object relationship authoritative and derive displayed counts asynchronously. Counts can briefly lag; expose reconciliation rather than blocking the interaction.
• One store versus specialized storesSeparate object storage, graph access, source metadata, and projections by access pattern. Cross-store workflows need events, repair jobs, and clear ownership boundaries.
• Synchronous versus asynchronous moderationRun cheap safety checks before publication and deeper scanning asynchronously. Every serving path must honor a later quarantine or deletion decision.