Instagram

Assume 1B daily active users. Each user opens the home feed 20 times per day on average, producing 20B feed page reads per day. Each page returns about 20 candidate items. Assume 300M durable feed posts per day and 1B story items per day.

Assume processed feed media averages 12 MB per post after originals, thumbnails, and multiple resolutions. Story media averages 5 MB and is hot for 24 hours before expiring from normal viewing. Assume 80B media impressions per day, an average delivered size of 700 KB after adaptive selection, 50B engagement events per day, a 10x peak multiplier, and 95 percent CDN hit ratio for media bytes.

• Feed writes: 300M posts per day divided by 86,400 seconds is about 3,472 posts per second, rounded to 3,500. A 10x multiplier gives about 35,000 creates per second.
• Story writes: 1B stories per day divided by 86,400 seconds is about 11,574 per second, rounded to 11,600. A 10x peak gives about 116,000 per second.
• Feed reads: 1B daily users times 20 feed opens per day gives 20B feed page reads. 20B divided by 86,400 seconds is about 231,000 reads per second average.
• Media impressions: 80B impressions per day divided by 86,400 seconds is about 926,000 media requests per second average. At 10x peak the CDN tier sees about 9.3M requests per second.
• Egress: 80B impressions times 700 KB is 56PB delivered per day. 56PB divided by 86,400 seconds is roughly 650GB per second average, with peak capacity in the multi-TB per second range.
• Durable media: 300M feed posts times 12 MB is 3.6PB of new processed media per day before replication. With three-way replication that is 10.8PB of physical writes before lifecycle optimization.
• Stories: 1B story items times 5 MB is 5PB of hot object data in the 24-hour visible window. Archive, compliance, or creator memories features can add a separate colder retention path.
• Metadata: 300M posts per day times a 2 KB post record is about 600GB of raw post metadata per day, or about 219TB per year before indexes and replicas.
• Engagement: 50B events per day divided by 86,400 seconds is about 579,000 events per second average. At 200 bytes per compact event, raw event input is about 10TB per day before compression.
• Fanout: 300M posts times 80 percent non-celebrity fanout times 300 followers produces 72B timeline entries per day. At 50 bytes per entry, that is about 3.6TB raw timeline-entry data per day before replication.

• users.username is unique for profile lookup.
• media_assets.owner_id, created_at supports upload libraries and ownership checks.
• posts.author_id, created_at supports profile grids and author timelines.
• posts.created_at is not enough for home feed; use timeline tables or ranking indexes keyed by viewer_id.
• follows.follower_id, followee_id should be unique and support both following and followers queries through two denormalized views.
• comments.post_id, created_at supports paginated comment threads.
• Counter and view events should not update the posts row synchronously on every action.

A user owns media assets and posts. A post references one or more media assets. Follows connect users and drive feed eligibility. Comments, likes, saves, and views reference posts, but high-volume interactions should be represented as idempotent event records plus aggregate counter tables rather than as hot columns on the post row.

Use object storage for media originals and variants. Use Cassandra, DynamoDB, Bigtable, or ScyllaDB for posts by author, timelines by viewer, story trays by viewer, and idempotent interaction records. Use a graph-shaped or denormalized follow store for follower and followee queries.

Use Redis or Memcached for feed page cache, post metadata cache, story tray cache, and hot counters. Use Elasticsearch, OpenSearch, Vespa, or a custom retrieval system for Explore candidates and text or hashtag search. Use OLAP storage such as Pinot, Druid, ClickHouse, BigQuery, or Snowflake for analytics, impressions, and creator insights.

The clean design keeps API servers out of the media byte path. The client first requests an upload intent, receives a short-lived presigned URL, uploads directly to object storage, and then references the resulting asset id when creating a post or story.

Object-created events trigger asynchronous workers. For photos, workers validate format, strip unsafe metadata, create thumbnails, produce multiple sizes, and write immutable variant keys. For videos, workers extract duration, generate poster frames, transcode into several resolutions and bitrates, and optionally package chunks for adaptive playback. The asset record should contain state, variant metadata, dimensions, checksum, and moderation labels.

The pipeline must be idempotent. Object notifications can be delivered more than once, workers can crash after writing some variants, and clients can retry post creation. Use deterministic variant keys, compare checksums, and transition state with conditional updates. Keep original media until all required variants are durable, then apply lifecycle policies to move originals or rarely used variants to colder storage.

Pure fanout-on-write gives very fast reads because each viewer has a precomputed timeline. It works well for normal users, but celebrity accounts with millions of followers create enormous write spikes and storage amplification. Pure fanout-on-read avoids write spikes, but every feed open must query many followed authors and rank their recent posts, which is too slow for heavy users.

Use a hybrid model. For ordinary authors, append the post id to each follower's timeline asynchronously. For high-follower accounts, do not push to every follower. Store their posts in author timelines and pull a bounded number during feed read. Merge pushed and pulled candidates, remove blocked or muted authors, apply freshness and ranking, and return a cursor.

The threshold should be operational, not fixed forever. A creator can cross the celebrity threshold during a viral moment. The system should track fanout cost, follower count, write lag, and engagement rate, then dynamically decide whether to push, pull, or selectively push to highly engaged followers.

Home feed ranking is constrained by eligibility: followed authors, privacy, mutes, blocks, close friends, age limits, and content safety labels. Within eligible candidates, rank by recency, affinity, predicted engagement, media quality, diversity, and negative feedback. Keep ranking features close to the feed service through feature caches so each feed read does not fan out to many online services.

Explore is different because it is not limited to followed accounts. It needs candidate generation from trending content, hashtags, audio, visual embeddings, collaborative filtering, and creator affinity. A retrieval service returns hundreds or thousands of candidates, then a ranker scores and filters them. For safety, content should be labeled before it is eligible for broad distribution.

Freshness and stability trade off. A feed that changes every refresh can feel random, while a stale feed reduces engagement. Use cursors, session-level dedupe, diversity constraints, and periodic reranking. When ranking is down, fall back to cached timelines, recent followed posts, and safe trending content.

A viral post can receive millions of views and likes in minutes. Updating one post row for every like or view creates a hot partition and makes user actions depend on counter storage. Instead, represent likes as idempotent user-post actions and views as events. Emit action and impression events to a stream, then aggregate in batches by post id and time bucket.

Exactness depends on the product surface. A viewer should see whether they personally liked a post with strong consistency by reading the user-post action record. The public like count can be eventually consistent and approximate. Views and unique viewers should use sampling, dedupe windows, and sketches such as HyperLogLog when exact uniqueness is too expensive.

Comments need stronger ordering than likes. Store comment records partitioned by post id and ordered by created_at or a time-sortable id. For very hot posts, split comments into pages, cache top comments, and separate comment_count aggregation from comment text storage.

Stories are high-write, high-read, and ephemeral. A story has media variants like a feed post, but its active visibility window is usually 24 hours. Store story metadata with expires_at and keep per-viewer story trays in cache or TTL-enabled wide-column tables.

TTL should remove stories from normal reads without requiring a perfectly timed sweeper. Reads must filter expired stories even if a cache entry lingers. Object storage lifecycle rules can delete active-window variants after the TTL, move archives to cold storage if the product supports memories, and retain only policy-required metadata.

Story views are especially write-heavy because every impression may create a viewer event. Use batched view recording, approximate counts for large creators, and per-author privacy rules. Close-friends and private-account stories require access checks before returning CDN URLs.

Partition posts by author_id plus time for profile grids, but partition feed timelines by viewer_id because home feed reads are viewer-centric. Partition comments by post_id, but add hot-post mitigation for celebrity comments. Partition media objects by hashed asset id and date to distribute object-store prefixes and lifecycle management.

Hot accounts create asymmetric load. A celebrity post can trigger huge fanout, ranking, notifications, counter updates, and CDN traffic. Use pull-based feed inclusion for these accounts, replicated metadata caches for hot posts, counter sharding, CDN prewarming for expected viral media, and rate-limited comment pagination.

Avoid one universal database. Instagram-like systems naturally use object storage, key-value stores, wide-column timeline tables, graph stores or denormalized follow tables, search indexes, caches, streams, and OLAP stores. The interview signal is knowing which access pattern owns each storage choice.

Alternative one is pure fanout-on-write. It makes feed reads extremely fast but is expensive for high-follower accounts and creates large write bursts.

Alternative two is pure fanout-on-read. It is simple to reason about and avoids timeline storage, but it cannot meet low-latency feed reads for users who follow many accounts unless the candidate set is heavily cached or capped.

Alternative three is synchronous media processing during upload. It gives a clean ready-or-fail response, but mobile clients wait longer, API capacity couples to transcoding, and retry behavior becomes painful. Asynchronous processing is usually the better tradeoff.

Do not use an Instagram-style architecture for a small private photo album or enterprise document repository. If the dominant requirements are strict access control, small group sharing, exact audit trails, and low traffic, a simpler object-storage-backed application with synchronous metadata writes is cheaper and safer.