Design Twitter (the feed problem)

The setup

You're interviewing for a senior backend role at a large social media company. The interviewer settles into the chair, opens their notebook, and says: "Let's design Twitter. Specifically the home timeline — the part where a user opens the app and sees recent tweets from people they follow. Think out loud as you go."

You have 60 minutes. The interviewer wants to see how you think, not whether you've memorized an answer. They'll push back at every architectural decision. The unstated test: can you balance competing concerns (read latency vs write cost vs operational complexity vs cost), articulate explicit tradeoffs, and adapt when challenged?

Many candidates fail this not because they don't know the technical pieces, but because they jump immediately to "we'll use Kafka and Cassandra." The interviewer doesn't learn anything from that. The good candidate spends the first 5-7 minutes locking down scope — because the design depends entirely on the answers.

The first 5 minutes: clarifying questions (don't skip)

Locked-in requirements

Functional:

• User can post a tweet (280 char text)
• User can follow / unfollow other users
• User can view their home timeline: recent tweets from followed users, reverse chronological
• User can view a user's profile timeline: that user's own tweets

Non-functional:

• 300M MAU; 500M tweets/day; 1M timeline reads/sec peak
• p99 timeline render < 200ms
• Eventual consistency acceptable (3-5 sec lag tolerable for new tweets)
• 99.9% availability
• Long-tail follower distribution (celebrities are first-class concern)

Back-of-envelope capacity estimation

Quantification is a senior reflex. Compute these numbers explicitly — they justify every later decision.

Tweet write rate:
  500M / day ÷ 86400 sec = ~5,800 tweets/sec average
  Peak (3× average during major events): ~17,000/sec

Read rate:
  200K timeline reads/sec average; 1M/sec peak

Tweet storage:
  Avg tweet: 280 chars + 200 bytes metadata = ~700 bytes
  500M × 700 = 350 GB/day raw tweets
  Annual: ~130 TB
  10-year: ~1.3 PB (with replication 3× = ~4 PB)

User & follow data:
  300M users × 1KB profile = 300 GB
  Avg follower count: ~200; total follow edges: 60B × 24 bytes = ~1.5 TB
  Sparsely sharded by user_id

Timeline cache footprint:
  300M users × 1000 cached tweet refs × ~80 bytes = ~24 TB
  But only 10% of users are "active" in a 24h window
  Active cache footprint: ~2.4 TB (fits in a Redis cluster)

Read bandwidth:
  1M reads/sec × 100KB payload = 100 GB/sec = 800 Gbps
  Need CDN + edge caching for timeline payloads

These numbers establish constraints: storage is petabyte-scale (commodity), reads dominate bandwidth (need caching), the cache fits in memory if you only cache active users.

The naive design (and exactly why it fails)

The intermediate engineer's instinct: just query.

SELECT t.* FROM tweets t
JOIN follows f ON t.user_id = f.followee_id
WHERE f.follower_id = $me
ORDER BY t.created_at DESC
LIMIT 100;

Why this fails at scale, quantitatively:

• A user who follows 1,000 people: the join touches potentially 1,000 partitions of the tweets table. Even if each partition lookup is 1ms (optimistic), that's 1 second per query.
• At 1M reads/sec across the cluster, you'd need 1M × 1 sec = 1M concurrent DB queries running. Impossible on commodity infrastructure.
• The ORDER BY DESC + LIMIT requires sorting matching rows — at scale, the sort itself dominates.
• Hot users (celebrities followed by millions) cause specific partitions to be hot — disproportionate read load on those shards.

The fundamental insight: at this scale, you don't compute the timeline on read; you precompute it on write. Or some hybrid. This single architectural pivot — moving work from read to write — is the central lesson of feed design.

Design Decision 1: Push vs Pull (the central tradeoff)

Two pure architectures, each with severe weaknesses:

Pure push fails on celebrities. Justin Bieber has 60M followers. When he tweets, fan-out is 60M cache writes. At 10ms per write with 1000 parallel workers: 60M / 1000 / 100 ops/sec = 600 seconds. Or with bigger fan-out workers: still minutes of work for one tweet. Meanwhile other writes pile up.

Pure pull fails on normal reads. A timeline read requires fetching from N followees' partitions. For a user following 500 people, that's 500 partition reads merged in real time. Even with sub-ms reads per partition, the total adds up; tail latency is awful.

The resolution: hybrid push-pull, segmented by follower count.

• For users below a threshold (e.g., < 10K followers): use push. Their fan-out is manageable. Their followers' timelines are precomputed.
• For users above the threshold ("celebrities"): use pull. Their tweets aren't fanned out; their followers' timelines pull live from celebrity tweet streams when reading.
• A user's home timeline is the MERGE of: (a) their precomputed inbox from non-celebrity follows, and (b) live-fetched recent tweets from celebrity follows.

This is approximately what real Twitter has done historically. The threshold is a tuning knob — set so that the system stays in the operating envelope.

Design Decision 2: Where do inboxes live?

Decision: Redis primary for active users; lazy compute + Redis populate for inactive users.

Memory math: 30M active users × 1000 cached tweet refs × ~80 bytes per ref = ~2.4 TB total cache footprint. Across a Redis cluster of 30 shards with replication: ~5 TB raw memory cost. At $1/GB/month: ~$5K/month for the timeline cache.

Each user's inbox is a Redis sorted set (ZSET) keyed by tweet_id, scored by timestamp. ZADD for inserts (fan-out worker), ZRANGE for reads (timeline service). Capped at 1000 entries per inbox via periodic ZREMRANGEBYRANK.

Design Decision 3: Tweet storage

Tweets need persistent storage. Access patterns:

• Write: append-only, ~17K/sec peak
• Read by tweet_id: lookups by single ID (timeline fetches the actual tweet content)
• Read by user_id: a user's profile timeline (their own tweets in time order)

Cassandra wins. Schema: tweets((user_id), created_at DESC, tweet_id). A user's tweets are co-located in one partition, sorted by recency. Reading "user X's last 20 tweets" is a single partition read.

For tweet_id lookups (when timeline returns IDs and we need content), a separate secondary table: tweets_by_id(tweet_id). Yes, this duplicates data — that's normal in Cassandra. Denormalize for query patterns.

The complete architecture

flowchart LR
    U[User posts tweet] --> API[API gateway]
    API --> WS[("Tweet store
(Cassandra)")]
    API --> FanQ[/Fan-out queue/]
    FanQ --> FW1[Fan-out worker]
    FanQ --> FW2[Fan-out worker]
    FW1 -->|look up followers| FG[("Follower graph")]
    FW2 --> FG
    FW1 -->|push tweet_id| IC[("Inbox cache
(Redis, per user)")]
    FW2 --> IC

    R[Reader requests timeline] --> TLS[Timeline service]
    TLS -->|"get inbox IDs"| IC
    TLS -->|"hydrate tweets"| WS
    TLS --> R

┌──────────────┐
│  Mobile/Web  │
└──────┬───────┘
       │
       ▼
┌──────────────────┐
│  API Gateway     │
└──┬───────┬───────┘
   │       │
   │       └─ Write path (POST /tweet)
   │           ↓
   │      ┌─────────────────┐
   │      │ Tweet Service   │
   │      └────────┬────────┘
   │               │
   │               ├──► Cassandra (tweets by user_id)
   │               │
   │               └──► Kafka topic: "tweet.posted"
   │                       ↓
   │                  ┌──────────────────────┐
   │                  │ Fan-out Worker Pool  │
   │                  └──────────┬───────────┘
   │                             │ For each follower (if not celebrity):
   │                             │   ZADD inbox:{follower_id} {tweet_id}
   │                             ▼
   │                       Redis Cluster (inboxes)
   │
   └─ Read path (GET /timeline)
       ↓
   ┌───────────────────────┐
   │ Timeline Service      │
   └────────┬──────────────┘
            │
            ├──► Redis: read inbox:{user_id}
            ├──► Cassandra: for each celebrity follow, fetch recent tweets
            ├──► Merge by timestamp; pick top-100 tweet_ids
            ├──► Cassandra: fetch tweet content by tweet_ids
            └──► Return assembled timeline

Cross-examination round 1: the celebrity problem

Cross-examination round 2: the inactive user problem

Cross-examination round 3: write amplification math

Failure mode analysis

Scaling phases

Operational considerations

• Observability: per-tier metrics (fan-out queue depth, Redis hit rate per shard, Cassandra partition latency p99, celebrity cache hit rate). SLO: 99.9% of timeline requests under 200ms.
• Capacity planning: Redis at <60% utilization; Cassandra at <50%; Kafka topic at <40% capacity. The fan-out worker pool auto-scales on queue depth.
• Deploys: timeline service and fan-out workers deploy independently. Backward-compatible Kafka message schemas (Avro with schema registry) — old workers can still consume new messages.
• Cost: at this scale, the dominant cost is Redis memory (~$10K-$50K/month for the active cache) and Cassandra storage (~$5K-$20K/month). LLM/ML costs if you add ranking later can dominate everything else.

Takeaway

The Twitter timeline problem has been the canonical feed design case study for over a decade. The lessons generalize to every similar system (Facebook feed, Instagram, LinkedIn, even Reddit). The core insight: at scale, you choose where the computation happens — write time or read time. Push (precompute) makes reads cheap but writes expensive; pull (compute on demand) inverts the cost. Almost every interesting feed/timeline/notification system in production uses a hybrid because the workload is heterogeneous. The hybrid isn't a compromise — it's a workload-fitted optimization.

The second lesson: the long tail dominates architectural complexity. If everyone had the same follower count, this would be a much simpler design. The fact that some users have 60M followers while most have 100 forces the hybrid. Whenever you see a heavy-tailed distribution in a system you're designing, expect to need a special path for the tail.