Twitter/X timeline

Same startup, same engineer #4. Fourth Monday of the year.

Your CTO drops by your desk with coffee. "Marketing loves the URL shortener and Slack, and Instagram is in beta. Now they want something more ambitious — a public microblogging feature. Users post short text and media. Followers see them in a reverse-chronological timeline. Handles like @jane. Direct messages. Ship an MVP in 12 weeks."

She pauses. "And by the way — one of our early beta users has 8 million followers. She just tweeted, and our L4 architecture melted."

That's the whole game.

Here's the pattern you've been building toward:

URL Shortener was read-heavy with tiny fanout (redirect happens 1:1).

Slack was real-time write-heavy but bounded fanout (channel of ~100 members).

Instagram shifted the paradigm — the ranking became the product, and follows became one signal among 50.

Twitter is the archetypal fanout problem. Every tweet from a regular user with 200 followers = 200 timeline writes. Every tweet from a celebrity with 50 million followers = 50 million writes. The push-fanout that works for 99% of users breaks catastrophically for 1% who drive 90% of engagement. Understanding this cliff — and how Twitter engineered around it — is the whole 12 chapters.

The real 2024 numbers

Before we design anything, know the real scale you're designing against:

• ~610M MAU (Reuters, Feb 2025), down from 250M+ DAU pre-2022
• ~500M tweets/day at peak (2013 peak was 500M/day, ~5,700 TPS average)
• Record peak: 143,199 TPS — set during a "Castle in the Sky" broadcast in Japan, 2013 (Twitter Engineering blog, 2013)
• Recent peak: 24,400 TPS — 2022 FIFA World Cup Final (Twitter Engineering, 2022)
• Top account (as of 2024): @elonmusk with 200M+ followers; @BarackObama with 130M+ (Wikipedia list)
• Timeline reads: ~10 billion/day at peak (2015)
• Read:write ratio: ~1000:1

Why 143,199 TPS is the interview soundbite: it was NOT sustained — it was a peak from a synchronized cultural event where an entire country tweeted the same word at the same second. Twitter's steady-state is much lower. Real interview greatness = knowing that number AND knowing when to say "but the sustained rate is closer to 6K TPS."

The whole journey at a glance

Every 10× in follower count forces a fundamentally different fanout strategy:

text
    ═══════════ TWITTER ARCHITECTURE ACROSS 4 SCALES ═══════════

    L4 (10K users)     L5 (10M users)     L6 (500M users)       L7 (X-scale, all-time)
    max ~10K followers max ~100K follwrs  max ~50M followers    max ~200M (Musk)
    12 weeks · $500/mo 6 months · $50K/mo 18 months · $500K/mo  ongoing · $1B+/yr

    ┌────────┐         ┌────────┐         ┌── Global CDN ──────┐  ┌── Own CDN + AI ────┐
    │  Web   │         │  Web   │         │  timeline + media  │  │  media + Grok LLM  │
    │ Mobile │         │ Mobile │         │  edge caches       │  │  edge inference    │
    └───┬────┘         └───┬────┘         └─┬──┬──┬──┬─────────┘  └──┬──┬──┬──┬──────┘
        │                  │                │  │  │  │               │  │  │  │
     ┌──▼───┐           ┌──▼──┐          ┌──▼──▼──▼──▼─────┐    ┌──▼──▼──▼──▼──────┐
     │ ALB  │           │ ALB │          │  Multi-region   │    │  20+ regions +   │
     │ HTTPS│           │ WSS │          │  ALB · anycast  │    │  anycast + BGP   │
     └──┬───┘           │ HTTPS│         └───┬──────┬──────┘    └────┬──────┬──────┘
        │               └──┬──┘             │      │                │      │
     ┌──▼──────┐       ┌───▼─────────┐   ┌──▼──────▼─────┐    ┌─────▼──────▼──────┐
     │ 1 API   │       │  API pods   │   │  Regional     │    │  Hybrid fanout    │
     │ server  │       │  sharded by │   │  API +        │    │  service:         │
     │         │       │  user_id    │   │  hybrid       │    │  push < 10K       │
     └──┬──────┘       │             │   │  fanout       │    │  pull > 10K       │
        │              └───┬─────────┘   │  service      │    │  celebrity model  │
        │                  │             └───┬───────────┘    └──┬──┬──┬──┬───────┘
        │              ┌───▼──┐          ┌───▼──────────┐        │  │  │  │
        │              │Redis │          │Redis Cluster │     ┌──▼──▼──▼──▼─────┐
        │              │timeln│          │timeline cache│     │Timeline Service │
        │              │cache │          │per-region    │     │(the OLD Manhattan)
        │              └───┬──┘          └───┬──────────┘     │+ RedisCluster    │
        │                  │                 │                └──┬──────────────┘
     ┌──▼───┐          ┌───▼─┐            ┌──▼──────────┐       │
     │MySQL │          │MySQL│            │Sharded MySQL│    ┌──▼──────────────┐
     │(user+│          │+ 2  │            │+ Manhattan  │    │Manhattan (2016+)│
     │ tweet│          │repl │            │Twitter's KV │    │KV store built at│
     │+follow          │icas │            │store (retire│    │Twitter 2014-16  │
     │Multi-│          │+ Kaf│            │d 2022 for X)│    │+ HDFS + Kafka +  │
     │AZ)   │          │ka   │            └─────────────┘    │ Flink for search │
     └──────┘          └─────┘                                └─────────────────┘

    ↑                  ↑                  ↑                       ↑
   Boring           Fan-out on write   Hybrid: push for regular   Multi-region.
   pull-based       for regular users. followers, pull-merge      Real-time search.
   JOIN works.     Kafka for celeb    for celebrities on read.    Grok LLM inference
                    events.            Manhattan KV store         is compute-bound,
                                       + Redis Cluster.           not I/O bound.

   Chapter 5      Chapters 6+6.5       Chapter 7+7.5              Chapter 8
   walks          walks through        walks through              walks through
   through        push-fanout +        the hybrid model,           X's post-2022
   L4 pull        Redis timeline       Manhattan history,          reorg + Grok +
   timeline in    cache                and the celebrity           multi-region
   full                                cliff at 10K followers      economics

  Key insight: 99% of Twitter users are fine with push fanout. 1% (celebrities)
  destroy the model. Twitter's ANSWER: HYBRID. Push for followers < 10K,
  pull-merge celebrity tweets at read time. That's the entire architecture story.

The same 4 tiers as clean architecture diagrams

The ASCII compressed all four tiers. Here are the same shapes as clean Mermaid — the kind an interviewer expects on a whiteboard:

L4 · 10K users · pull-based JOIN · $500/mo · 12 weeks:

L5 · 10M users · push-fanout for everyone · $50K/mo · 6 months:

L6 · 500M users · hybrid push/pull · $500K/mo · 18 months:

L7 · 610M+ MAU · X-scale + Grok LLM + custom silicon · $1B+/yr:

Why every 10× breaks the architecture

Look at the four tiers side by side. Two patterns dominate:

1. Storage stays boring. MySQL → Sharded MySQL → Manhattan + Cassandra. Boring engineering, and it's fine.

1. Fanout mutates. L4 pull → L5 push → L6 hybrid → L7 hybrid + ML rerank. The fanout strategy IS the architecture.

The celebrity cliff: at ~10K followers, push-fanout starts costing more than pull-merge on read. Twitter engineered a hybrid ~2012: push if followers < 10K, pull-merge everyone else's celebrity tweets at read time. Reference: Twitter Engineering: "The Infrastructure Behind Twitter: Scale".

Why not push everything? At Elon's 200M followers, a single tweet = 200M timeline writes. Even at 10K writes/sec/node = 20K node-seconds = 5.5 hours to fully fan out. Pull-merge on read is O(N) reads at 200M × ~5% online = 10M timeline requests over a few hours. Cheaper, faster, correct.

Why not pull everything? At L5 with 10M users each following 200 users, every timeline read = 200 tweet_id fetches = 200 Redis calls. Redis handles this, but ballooned reads at billions per day = massive Redis costs. Push is dramatically cheaper for the 99% of users with < 10K followers.

The 3 senior insights before we start Chapter 1

1. The problem is NOT storage — it's the fanout curve. Every candidate memorizes "we shard MySQL." That's fine. What Twitter engineered is the decision boundary between push and pull, which is more interesting than any DB choice.

1. Manhattan is NOT Cassandra. Twitter built its own KV store (Manhattan) in 2014 for tweet metadata — because Cassandra's eventual-consistency semantics didn't fit their SLA. Reference: Twitter Engineering: "Manhattan, our real-time, multi-tenant distributed database". Do NOT say "Twitter uses Cassandra for tweets" — that's a common tutorial-parrot mistake.

1. The 143K TPS record is a peak, not a baseline. Baseline is ~6K TPS. Interviewers love asking "how do you handle 143K TPS?" — the right answer is "we don't design for that; we design for the 24K TPS World Cup peak (sustained ~30 min) and let Kafka queue absorb the microsecond bursts."

Chapter map for the journey ahead

• Chapter 1 — Requirements (functional + non-functional per level)
• Chapter 2 — Capacity estimation (610M MAU, 500M tweets/day, 10B timeline reads/day)
• Chapter 3 — API design (tweet, timeline, follow, DM, search)
• Chapter 4 — Data model (users, tweets, follows — and the graph problem)
• Chapter 4.5 — The follows graph: adjacency list vs graph DB vs materialized fanout
• Chapter 5 — L4 MVP: pull-based JOIN. Works up to ~10K users
• Chapter 6 — L5: push-fanout with Kafka + Redis
• Chapter 6.5 — The celebrity cliff. Hybrid push/pull decision matrix
• Chapter 7 — L6: Manhattan KV store, Redis Cluster, multi-region
• Chapter 7.5 — The tweet ranking + search pipeline (Elasticsearch + Flink)
• Chapter 8 — L7: X-scale + Grok + real-time ML reranking
• Chapter 9 — Failure modes: celebrity death spiral, timeline cache stampede, follow-graph inconsistency
• Chapter 10 — Trade-off matrix
• Chapter 11 — Interview masterclass: 45-min mock, questions to ask
• Chapter 12 — Defense: the 20 hardest interview questions on Twitter

Ready? Chapter 1 next: what did the CTO actually ask for?