Twitter Feed — Fanout-on-Write (CQRS-Lite Push Model)

The fanout-on-write (push model) architecture is the standard production approach used by social feed platforms handling millions of feed reads per second. It solves the fundamental problem that makes the naive fanout-on-read approach unworkable: the O(following_count) database queries per feed read that overwhelm the database at a few hundred concurrent users.

The key architectural shift is reversing where the computational cost lives. Instead of computing feeds at read time (O(N) queries per read, O(1) per write), feeds are pre-computed at write time: when a user posts a tweet, the system pushes the tweet ID into every follower's cached feed in Redis. This makes reads O(1) — a single Redis LRANGE returning 20 tweet IDs in ~2ms — at the cost of O(N) cache writes per tweet, where N is the author's follower count.

This cost reversal is a massive net win because social feeds have extremely asymmetric traffic: reads outnumber writes by 100:1 or more. Converting 1 expensive write into N cache writes that make 100+ reads free is one of the most powerful optimizations in distributed systems. The write cost is further amortized by making fanout asynchronous via Kafka — the user sees 'tweet posted' immediately while workers fan out in the background.

The architecture uses CQRS-lite: an API Gateway splits traffic by HTTP method. GET requests (feed reads, profile views) route to the read path — FeedReader service backed by Redis cache with DynamoDB fallback. POST requests (tweet posts, likes) route to the write path — TweetWriter service that persists to DynamoDB and publishes events to Kafka. FanoutWorkers consume from Kafka and complete the write-amplification loop by pushing tweet IDs into followers' cached feeds.

The primary limitation is the 'whale problem': a celebrity with 50 million followers triggers 50 million Redis writes per tweet. At 5 microseconds per write, that is 250 seconds of work — a 4-minute backlog per celebrity tweet. This pure push model does NOT solve the whale problem. The Hybrid Push+Pull variant addresses this by using fanout-on-read for high-follower accounts.

This architecture appears in virtually every system design interview for social media roles. Interviewers expect candidates to explain the read/write cost reversal, articulate the Kafka decoupling pattern, reason about cache consistency, and identify the whale problem as the motivation for the hybrid approach.

The fanout-on-write system uses 9 components organized into a CQRS-lite pipeline with separate read and write paths. The components are: ReadClient, WriteClient, API Gateway, Read Load Balancer, Write Load Balancer, FeedReader service, TweetWriter service, FeedCache (Redis), TweetStore (DynamoDB), FanoutStream (Kafka), and FanoutWorker.

All traffic enters through the API Gateway, which performs JWT authentication (~3ms), rate limiting (250K RPS cap), and CQRS routing. GET requests (feed reads, profile views — 76% of traffic) route to the Read Load Balancer, which distributes across 15 FeedReader pods. POST requests (tweet posts, likes — 24% of traffic) route to the Write Load Balancer, which distributes across 10 TweetWriter pods.

The read path is optimized for speed. FeedReader checks the user's pre-computed feed in FeedCache (Redis). At ~92% cache hit rate, most feeds are served from Redis in ~2ms via LRANGE on a bounded list of tweet IDs. On cache miss (new user, cold start, expired TTL), FeedReader falls back to TweetStore (DynamoDB) to reconstruct the feed from followed users' recent tweets and backfills the cache. The read path is the highest-throughput component: 15 pods handle 152K peak read RPS.

The write path handles persistence and fanout initiation. TweetWriter validates the tweet, persists to TweetStore (DynamoDB — durable write, ~50ms), and publishes a tweet_created event to FanoutStream (Kafka). The Kafka publish is fire-and-forget — the HTTP response returns as soon as the DB write succeeds. Likes update the like counter in DynamoDB but do NOT trigger fanout.

The fanout pipeline is fully asynchronous. FanoutWorkers consume tweet_created events from Kafka (64 partitions, partitioned by author_id for ordering). For each event, the worker looks up the author's follower list and writes the tweet ID into each follower's pre-computed feed in FeedCache via Redis LPUSH + LTRIM. At 200 average followers per tweet, each event generates ~200 cache writes. With 80 parallel workers and pipelined Redis writes, fanout completes within seconds for most users.

The architecture scales horizontally at each tier. FeedReader pods scale with read RPS. TweetWriter pods scale with write RPS. FanoutWorkers scale with fanout volume. FeedCache nodes scale with working set size. Each tier can be scaled independently without affecting the others — this is the core benefit of the CQRS split.