Twitter Feed — Naive (Fanout-on-Read / Pull Model)

Designing a Twitter-like news feed is one of the most frequently asked system design interview questions because it forces candidates to reason about the fundamental trade-off between read cost and write cost. The naive fanout-on-read approach is where every candidate should start — it establishes the baseline that makes the improvements in fanout-on-write architectures measurable and concrete.

The core challenge is delivering a personalized timeline: each user sees a chronological feed of tweets from accounts they follow. In the naive approach, this is computed on every read. When a user opens their feed, the server (1) queries the follows table to get all followed user IDs, (2) fetches recent tweets from each followed user, (3) merges and sorts by timestamp, and (4) returns the top 20. At 200 average follows per user, this means approximately 201 database queries per feed request.

The pull model's fatal flaw is the read amplification. Each feed request generates O(following_count) database queries. At 500 concurrent users with 60% feed reads and 200 average follows, the database handles 60,000 queries per second — far beyond what a single PostgreSQL instance can sustain. The connection pool saturates, feed latency climbs from 150ms to multiple seconds, and the system hits a hard ceiling. Meanwhile, the write path is trivially cheap: posting a tweet is a single INSERT.

This asymmetry between read cost and write cost is the key insight interviewers are looking for. In a social feed workload, reads outnumber writes by 100:1 or more. The naive approach puts all the cost on the read side (O(N) queries per read, O(1) per write), when the optimal strategy is to shift cost to the write side (O(1) per read, O(N) per write via fanout-on-write). The Fanout-on-Write variant demonstrates this reversal: pre-computing feeds at write time reduces reads to a single Redis LRANGE in 2ms.

This template makes the read amplification visible and quantifiable. Run the simulation at increasing user counts and watch the database become the bottleneck while the service layer sits idle. The comparison with the Fanout-on-Write and Hybrid variants provides the concrete numbers to support the discussion of read/write trade-offs that interviewers expect.

Twitter feed design appears in interviews at Twitter/X, Meta, Threads, Bluesky, Mastodon, and virtually every company with a social product. Interviewers expect candidates to start with the pull model, identify the O(N) read problem, and propose fanout-on-write as the first optimization — then discuss the whale problem that motivates the hybrid approach.

The naive Twitter feed system is a four-component linear architecture: Client, Load Balancer, Tweet Service, and PostgreSQL database. There is no cache, no event stream, no fanout workers, and no separation between the read and write paths.

All traffic enters through the Load Balancer, which distributes requests across Tweet Service pods using round-robin. The Load Balancer adds approximately 1.5ms of routing latency and supports up to 5,000 RPS — well above the system's actual ceiling, which is determined by the database. Both feed reads and tweet posts flow through the same LB and service — there is no CQRS split.

The Tweet Service is a stateless REST API running on 3 pods with 50 threads each. It handles four operations: (1) feed read — query the follows table for all followed user IDs, then fetch recent tweets from each followed user, merge-sort by timestamp, return top 20; (2) tweet post — validate and INSERT into the tweets table; (3) profile view — query a single user's profile and recent tweets; (4) follow/unfollow — INSERT or DELETE in the follows table. The service processing time is approximately 8ms, but feed read latency is dominated by the O(following_count) database queries.

PostgreSQL stores three tables: tweets, users, and follows. The tweets table is the hottest — it receives INSERTs on every tweet post and is the target of O(N) SELECT queries on every feed read. A B-tree index on (author_id, created_at DESC) supports per-author tweet queries but causes write amplification on every INSERT. The follows table is queried on every feed read to determine who the user follows. The users table stores profile data and is rarely a bottleneck.

The system has no redundancy at the data layer. A single PostgreSQL primary handles all reads and writes. If the database fails, both feed reads and tweet posts stop entirely. There is no cache, so every feed read hits the database with hundreds of queries. There is no deduplication, no event stream, and no pre-computation.

The concrete scaling ceiling is approximately 500 concurrent feed readers. At this point, 300 feed reads per second x 200 queries each = 60,000 database queries per second. The connection pool (100 connections) saturates, feed latency degrades from 150ms to multiple seconds, and tweet write latency spikes as writes compete with reads. The system degrades gracefully until approximately 1,000 users, where connection pool exhaustion causes outright errors.