System design: Twitter/X — feed de notícias em escala

Tweets/dia: 500.000.000
Tweets/segundo: 500M / 86.400 ≈ 5.800/s (média)
Pico: ~15.000 tweets/s

Tamanho médio de tweet: ~1 KB (texto + metadata)
Com mídia (20% dos tweets têm imagem): média geral ~5 KB
Storage de tweets/dia: 500M × 5 KB = ~2.5 TB/dia

DAU: 400.000.000
Timeline refreshes/dia por user: ~20 (abre app, scroll, pull-to-refresh)
Total reads/dia: 400M × 20 = 8.000.000.000 (8 bilhões)
Reads/segundo: 8B / 86.400 ≈ 92.500/s
Pico: ~300.000 reads/s

Tweets/segundo: 5.800
Média de followers por autor: ~500 (mediana é baixa, média é puxada por celebridades)
Fan-out writes/segundo: 5.800 × 500 = 2.900.000/s

MAS: se incluir tweets de contas com milhões de followers:
  1 tweet de conta com 50M followers = 50M timeline writes
  Se 10 contas assim tweetam por minuto = 500M writes/minuto = 8.3M/s

Cada timeline armazena últimos ~800 tweet IDs
400M users × 800 IDs × 8 bytes (int64) = ~2.5 TB

@alice tweeta (tem 1000 followers)
  → Escreve tweet_id na timeline de cada um dos 1000 followers
  → Quando follower abre app: timeline já está pronta, só ler

Prós: leitura instantânea (timeline pré-computada)
Contras: escrita é cara (N writes por tweet, onde N = followers)

@bob abre o app (segue 500 contas)
  → Sistema busca últimos tweets de cada uma das 500 contas
  → Merge + sort por timestamp
  → Retorna timeline

Prós: escrita é simples (só salvar o tweet uma vez)
Contras: leitura é cara (N queries por timeline load, onde N = following)

┌─────────────────────────────────────────────────────────────────────┐
│                          HYBRID FAN-OUT                               │
├─────────────────────────────────────────────────────────────────────┤
│                                                                       │
│  Usuário normal (< 500K followers):                                  │
│    → Fan-out on WRITE                                                 │
│    → Tweet é pushado pra timeline de cada follower                   │
│    → Read é O(1): timeline já está montada no cache                  │
│                                                                       │
│  Celebridade (> 500K followers):                                     │
│    → Fan-out on READ                                                  │
│    → Tweet é salvo, mas NÃO pushado                                  │
│    → Na hora do read: merge timeline pré-computada + tweets          │
│      recentes das celebridades que o user segue                      │
│                                                                       │
└─────────────────────────────────────────────────────────────────────┘

┌─────────────────────────────────────────────────────────────────────┐
│                         WRITE PATH (Tweet)                            │
├─────────────────────────────────────────────────────────────────────┤
│                                                                       │
│  User ──→ API Server ──→ Tweet Service ──→ Tweet Storage             │
│                               │                                       │
│                               ▼                                       │
│                        Fan-out Service                                 │
│                          │         │                                  │
│                          ▼         ▼                                  │
│              [normal user]    [celebrity]                              │
│              Push to Redis    Só armazena                              │
│              timelines        (merge no read)                         │
│                                                                       │
│                               │                                       │
│                               ▼                                       │
│                     Search Index (async)                               │
│                     Trending Service (async)                           │
│                                                                       │
└─────────────────────────────────────────────────────────────────────┘

┌─────────────────────────────────────────────────────────────────────┐
│                         READ PATH (Timeline)                          │
├─────────────────────────────────────────────────────────────────────┤
│                                                                       │
│  User ──→ API Server ──→ Timeline Service                            │
│                               │                                       │
│                     ┌─────────┴──────────┐                           │
│                     ▼                    ▼                            │
│            Redis Timeline         Celebrity Tweet Cache               │
│            (pré-computada)        (últimos tweets de VIPs             │
│                     │              que este user segue)               │
│                     └─────────┬──────────┘                           │
│                               ▼                                       │
│                          Merge + Rank                                 │
│                               │                                       │
│                               ▼                                       │
│                      Hydrate (buscar tweet completo)                  │
│                               │                                       │
│                               ▼                                       │
│                          Response                                     │
│                                                                       │
└─────────────────────────────────────────────────────────────────────┘

POST /v1/tweets

// Request
{
  "content": "System Design na Prática - nova série no blog!",
  "media_ids": ["media_abc123"],
  "reply_to": null
}

// Response (201 Created)
{
  "id": "tweet_789xyz",
  "author_id": "usr_ricardo",
  "content": "System Design na Prática - nova série no blog!",
  "media": [{"id": "media_abc123", "url": "https://cdn.example.com/..."}],
  "created_at": "2026-05-23T10:30:00Z",
  "metrics": {"likes": 0, "retweets": 0, "replies": 0}
}

GET /v1/timeline/home?cursor=eyJ0cyI6MTcxNjQ1...&limit=20

// Response (200 OK)
{
  "tweets": [
    {
      "id": "tweet_789xyz",
      "author": {"id": "usr_ricardo", "name": "Ricardo", "handle": "@ricardomartins"},
      "content": "System Design na Prática...",
      "created_at": "2026-05-23T10:30:00Z",
      "metrics": {"likes": 42, "retweets": 7, "replies": 3}
    }
  ],
  "next_cursor": "eyJ0cyI6MTcxNjQ0...",
  "has_more": true
}

GET /v1/search/tweets?q=system+design&cursor=...&limit=20

GET /v1/trends?location=brazil

{
  "trends": [
    {"name": "#SystemDesign", "tweet_count": 45200, "context": "Technology"},
    {"name": "ChatGPT", "tweet_count": 128000, "context": "Technology"},
    {"name": "#BBB26", "tweet_count": 890000, "context": "Entertainment"}
  ]
}

1. Tweet salvo no Tweet Storage
2. Evento publicado no Kafka: "new_tweet:{tweet_id}:{author_id}"
3. Fan-out Service consome o evento
4. Consulta Social Graph: "quem segue author_id?"
5. Classifica o autor:
   - Normal (< 500K followers) → fan-out on write
   - Celebrity (> 500K followers) → skip fan-out, só cachear tweet

6. Fan-out on write (usuário normal):
   Para cada follower_id:
     LPUSH timeline:{follower_id} tweet_id
     LTRIM timeline:{follower_id} 0 799  (manter só últimos 800)

followers = get_followers(author_id)  // ex: 50.000 followers
batches = chunk(followers, 1000)      // 50 batches de 1000

for batch in batches:
  pipeline = redis.pipeline()
  for follower_id in batch:
    pipeline.lpush(f"timeline:{follower_id}", tweet_id)
    pipeline.ltrim(f"timeline:{follower_id}", 0, 799)
  pipeline.execute()  // 1 round-trip pro Redis pra 1000 ops

followers = get_followers(author_id)
active_followers = filter(followers, last_active < 30_days_ago)
// 50.000 followers → talvez 20.000 realmente ativos

Kafka topic "fanout-jobs" com 64 partitions
Cada partition processa um subset de followers

Tweet do @ricardo (100K followers):
  Partition 0: followers[0:1562]
  Partition 1: followers[1563:3124]
  ...
  Partition 63: followers[98438:100000]

64 workers processam em paralelo → fan-out em < 1 segundo

190.000.000 Redis writes
A 100.000 writes/s por Redis cluster = 1.900 segundos = 31 minutos

1. Tweet do Elon é armazenado num cache separado: celebrity_tweets:{author_id}
2. Não faz fan-out
3. Quando user abre timeline:
   a. Busca timeline pré-computada do Redis (tweets de users normais)
   b. Busca quais celebridades este user segue
   c. Pra cada celebridade: busca últimos tweets do celebrity cache
   d. Merge todos os tweets por timestamp/ranking
   e. Retorna resultado final

Redis Key: timeline:{user_id}
Redis Type: List (LPUSH/LRANGE)
Content: últimos 800 tweet_ids (não o tweet completo)

Exemplo:
  timeline:usr_bob = [tweet_999, tweet_998, tweet_995, tweet_990, ...]

1. GET /v1/timeline/home?limit=20

2. Timeline Service:
   a. LRANGE timeline:{user_id} 0 19 → [tweet_ids]
   b. Se user segue celebridades:
      celebrity_ids = get_celebrity_following(user_id)
      for celeb in celebrity_ids:
        LRANGE celebrity_tweets:{celeb} 0 4 → [more_tweet_ids]
   c. Merge + sort por timestamp (ou ranking score)
   d. Top 20 tweet_ids

3. Hydration:
   MGET tweet:{id1} tweet:{id2} ... tweet:{id20}
   → Retorna tweets completos (content, author, metrics)
   → Cache hit rate >99% pra tweets recentes

4. Response ao client

User segue 200 contas
  → Trigger async job: "build initial timeline"
  → Busca últimos 800 tweets de todas as 200 contas (fan-out on read, uma vez)
  → Merge + sort
  → Popula timeline:{user_id} no Redis
  → A partir de agora, fan-out on write mantém atualizado

Relação: follower_id → followee_id (direcional)

Total de relações: 400M users × média 500 following = ~200 bilhões de edges

-- Sharded por follower_id
CREATE TABLE follows (
    follower_id BIGINT,
    followee_id BIGINT,
    created_at TIMESTAMP,
    PRIMARY KEY (follower_id, followee_id)
);

-- Index reverso (sharded por followee_id)
CREATE TABLE followers (
    followee_id BIGINT,
    follower_id BIGINT,
    created_at TIMESTAMP,
    PRIMARY KEY (followee_id, follower_id)
);

"Quem @alice segue?" (pra montar timeline)
→ SELECT followee_id FROM follows WHERE follower_id = 'alice'

"Quem segue @elon?" (pra fan-out)
→ SELECT follower_id FROM followers WHERE followee_id = 'elon'
  → 190M rows. Não dá pra buscar tudo de uma vez.
  → Paginação: cursor-based, processado em batches pelo fan-out service

"@alice segue @bob?" (pra mostrar botão follow/following)
→ EXISTS em follows(alice, bob) — O(1) com primary key

Redis Set: following:{user_id} = {followee_1, followee_2, ...}
Redis Set: followers:{user_id} = {follower_1, follower_2, ...}

Pra users normais: set completo no Redis
Pra celebridades: não cachear followers (190M no Redis = ~1.5 GB só pra um user)
  → Usar streaming do DB (cursor-based scan)

Trending score = (volume_atual - volume_baseline) / tempo

Todos os tweets
       │
       ▼
  Stream Processor (Kafka Streams / Flink)
       │
       ├── Extrai entidades: hashtags, mentions, keywords
       │
       ├── Conta frequência por janela de tempo (sliding window)
       │     └── Janelas: 5min, 15min, 1h, 4h
       │
       ├── Calcula taxa de crescimento vs baseline
       │     └── baseline = média dos últimos 7 dias pra aquela hora
       │
       ├── Filtra: remove spam, conteúdo proibido, ruído
       │
       └── Ranking: top N por região/país/global
              │
              ▼
       Trending Cache (Redis, TTL 1-5 min)

Time buckets de 1 minuto cada:
  bucket[14:30] = CountMinSketch (todas as hashtags nesse minuto)
  bucket[14:31] = CountMinSketch
  ...
  bucket[14:44] = CountMinSketch

Contagem dos últimos 15 min de "#SystemDesign":
  sum(bucket[14:30..14:44].count("#SystemDesign"))

Tweet com geo = São Paulo
  → Conta em: trending:global, trending:brazil, trending:sao_paulo

User pede trends:
  GET /v1/trends?location=brazil
  → Retorna merge de trending:brazil (peso alto) + trending:global (peso baixo)

Novo tweet
    │
    ▼
Kafka → Search Indexer → Elasticsearch Cluster
                              │
                              ├── Index recente (últimos 7 dias) — SSD, réplicas
                              └── Index histórico (> 7 dias) — HDD, menos réplicas

Search query
    │
    ▼
Search Service → Elasticsearch
    │
    ├── Query no index recente (prioridade)
    ├── Se precisa mais resultados: query no histórico
    │
    ▼
  Merge + Rank + Return

Kafka consumer (search indexer):
  1. Consome tweet do topic
  2. Tokeniza: extrai palavras, hashtags, mentions
  3. Index no Elasticsearch com near-real-time refresh (1 segundo)

score = text_relevance (BM25)
      × recency_boost (tweets recentes rankeiam melhor)
      × engagement_signal (likes, retweets amplificam)
      × author_authority (verified, follower count)
      × personalization (seus interesses, quem você segue)

Like event
    │
    ▼
Redis: INCR tweet_likes:{tweet_id}   (instantâneo, in-memory)
    │
    ▼ (async, batched, a cada 5-10 segundos)
Persistence job: UPDATE tweets SET likes = {redis_value} WHERE id = X

Cache policy pra tweet com métricas:
  < 100 likes: atualiza em real-time (baixo volume)
  100-10K likes: atualiza a cada 30 segundos
  > 10K likes: atualiza a cada 5 minutos (ninguém nota diferença)

CREATE TABLE tweets (
    id BIGINT PRIMARY KEY,  -- Snowflake ID (timestamp-encoded)
    author_id BIGINT NOT NULL,
    content VARCHAR(280),
    media_urls JSONB,
    reply_to_id BIGINT,
    retweet_of_id BIGINT,
    like_count INT DEFAULT 0,
    retweet_count INT DEFAULT 0,
    reply_count INT DEFAULT 0,
    created_at TIMESTAMP,
    
    INDEX idx_author (author_id, created_at DESC)
);

| 41 bits: timestamp (ms) | 10 bits: machine ID | 12 bits: sequence |
|       ~69 anos           |    1024 machines    |   4096 IDs/ms    |

Redis Cluster (128+ shards):
  Key: timeline:{user_id}
  Type: List
  Content: últimos 800 tweet_ids
  Memory per user: 800 × 8 bytes = 6.4 KB
  Total: 400M × 6.4 KB = ~2.5 TB

Tweet Cache:
  Key: tweet:{tweet_id}
  Type: Hash
  Content: tweet completo serializado (~1 KB)
  Hot tweets (últimas 24h): ~500M × 1 KB = 500 GB

1. Marca tweet como deleted no Tweet Storage
2. NÃO remove das 50K timelines (seria fan-out de delete — caro)
3. Na hora do read, durante hydration:
   - Se tweet está deleted → skip, não mostra
   - Timeline fica com "buraco" que é ignorado
4. Eventualmente, background job limpa IDs deletados das timelines

1. Remove follow relationship
2. Na hora do read:
   - Se tweet.author_id NÃO está em following:{user_id} → skip
3. Background job limpa tweets do unfollowed da timeline (async, low priority)

1M requests/s pra tweet:{viral_id}
  → Redis hot key problem (um key recebe todo o tráfego)

1. Alice segue Elon
2. Elon é celebrity → sem fan-out on write
3. Timeline service sabe que Alice segue celebrity "elon"
4. No próximo read, inclui tweets recentes do celebrity_tweets:elon no merge
5. Sem necessidade de reprocessar timeline inteira