Design Instagram — System Design Interview Practice

Interview prompt

Design Instagram for hundreds of millions of daily users: people upload photos and videos, follow accounts, read a personalized feed, publish expiring stories, and receive media and interaction updates reliably.

• Separate durable media metadata and social graph state from object storage, CDN delivery, and rebuildable feed projections.
• Choose fanout-on-write, fanout-on-read, or a hybrid strategy for normal and celebrity accounts.
• Design resumable uploads, asynchronous processing, privacy and moderation checks, and idempotent interaction events.
• Bound feed reads and story expiry work while making freshness, deletion, and regional failure behavior explicit.

Requirements and scale assumptions

• Upload photos and videos, generate multiple renditions, and publish a post or 24-hour story.
• Follow and unfollow users, read a personalized feed, and view a profile timeline.
• Like, comment, share, and receive notifications for eligible interactions.
• Search users and hashtags while enforcing private accounts, blocks, moderation, deletion, and data export rules.
• A post's metadata and ownership must be durable before publication; media processing may complete asynchronously.
• Target p95 under 200 ms for a cached feed page and under 2 seconds for normal media availability after upload.
• Serve popular media through a CDN, isolate celebrity fanout, and avoid blocking reads on recommendation or moderation workers.
• Tolerate resumable upload retries, worker failures, duplicate events, story expiry races, and regional degradation.
• 500 million daily active users, 100 million media uploads per day, and 10 million concurrent feed or story viewers at peak.
• Most users follow fewer than 1,000 accounts; a small number of creators have tens of millions of followers.
• Each upload produces several image or video renditions; originals and derivatives are stored in object storage with lifecycle tiers.
• Stories expire after 24 hours, but deletion and privacy changes must invalidate them immediately from serving paths.

• Media upload rate: ~1.2K/s avg — 100M uploads per day; provision ingestion, object storage, and processing for event bursts.
• Feed read latency: p95 <=200ms — Serve a bounded cursor page from projections and cache without scanning the social graph.
• Media readiness: p95 <=2s — Upload acknowledgement is immediate; normal renditions become playable asynchronously within this target.
• Story lifetime: 24 hours — TTL is a serving rule, backed by durable state and explicit deletion or moderation invalidation.

Key entities

• MediaAssetmediaId, ownerId, objectUri, renditions, visibility, status

  Canonical uploaded photo/video and processing state.

• FollowEdgefollowerId, followeeId, status, version, createdAt

  Versioned graph relationship used for feed fanout and authorization.

• FeedItemviewerId, postId, rank, sourceVersion, createdAt, expiresAt

  Materialized home-feed item with generation metadata.

• InteractioninteractionId, mediaId, actorId, type, version, occurredAt

  Like/comment/save/report transition used by projections and moderation.

Data flow

1. 1. Upload and publish mediaThe client uploads to object storage; metadata, ownership, visibility, checksum, and moderation state are committed before publication.
2. 2. Maintain the social graphFollow/unfollow edges are conditionally written and publish graph events that affect feed candidates and authorization.
3. 3. Build home-feed candidatesFanout workers push ordinary posts to follower partitions, while high-follower accounts are pulled or hybrid-fanned out at read time.
4. 4. Serve feed and storiesFeed and story services merge ranked candidates, check visibility and expiry, and return cursor/freshness metadata.
5. 5. Process interactions and moderationLike/comment/report events update projections, notifications, discovery, and safety queues asynchronously with repairable state.

Deep dives and trade-offs

• Fanout strategy and hot creatorsFor Instagram's media, graph, feed, and story platform, a user's feed must contain only visible, non-expired content from the current graph and policy versions. Design for the failure case where celebrity fanout, upload bursts, deletes, and policy changes must not overwhelm writes or expose content; keep retries, versions, and repair state explicit. Expose freshness, version, lineage, or audit metadata so operators and clients can distinguish current, pending, and degraded state.
• Media processing and lifecycleFor Instagram's media, graph, feed, and story platform, a user's feed must contain only visible, non-expired content from the current graph and policy versions. Keep this concern off unrelated request paths and partition it by Instagram's media, graph, feed, and story platform access key. Expose freshness, version, lineage, or audit metadata so operators and clients can distinguish current, pending, and degraded state.
• Graph authorization and moderationFor Instagram's media, graph, feed, and story platform, a user's feed must contain only visible, non-expired content from the current graph and policy versions. Keep this concern off unrelated request paths and partition it by Instagram's media, graph, feed, and story platform access key. Expose freshness, version, lineage, or audit metadata so operators and clients can distinguish current, pending, and degraded state.
• Fanout-on-write versus fanout-on-readUse a hybrid: push normal creators to feed partitions and pull high-fanout creators when the viewer reads. Pure push creates massive write amplification; pure pull makes home-feed latency and ranking expensive.
• Strong graph reads versus cached feedCommit graph edges strongly and let feed projections converge with invalidation and policy checks on read. A feed cache without visibility checks can show content after unfollow, block, or delete.
• Original media retention versus delivery costKeep originals in durable tiered storage and generate policy-approved renditions behind a CDN. Keeping every rendition hot is expensive; deleting originals too early prevents reprocessing.