Case Study: Twitter/X

Когда Илон Маск пишет твит, он создаёт 150 миллионов записей в базе. Без trick'а с celebrity cutoff Twitter упал бы на каждом таком твите.

• Twitter/X: 500M твитов/день, 200M DAU, 6M QPS на чтение timeline в пике.
• Cristiano Ronaldo - 600M followers; один пост создаёт fan-out, превышающий весь дневной write-traffic малой соцсети.
• Twitter 2010-2012: классические FailWhale-аутажи именно из-за наивного fan-out на celebrity-аккаунтах.
• Manhattan (Twitter NoSQL, 2014): write throughput - 10M ops/sec, latency P99 < 10ms; построен поверх множества MySQL-шардов.

Цели урока

• Понять fan-out problem и его решения
• Спроектировать hybrid fan-out (push + pull)
• Использовать Redis Sorted Sets для pre-computed timelines
• Выбрать правильные базы данных для разных access patterns
• Масштабировать систему до сотен миллионов пользователей

Предварительные знания

• Message Queue для async processing
• Понимание кеширования и Redis
• Базовые знания о NoSQL (Cassandra)

Требования и масштаб

**Задача**: спроектировать социальную сеть типа Twitter. Пользователи постят твиты, подписываются друг на друга, читают ленту.

**Главный challenge**: 6M QPS на чтение timeline. Каждый timeline = твиты от сотен подписок. Наивный подход не сработает.

Fan-out Problem

Когда @elonmusk (150M followers) постит твит, как доставить его в 150 миллионов лент? Это **fan-out problem**.

Ни один подход не идеален. Twitter использует **гибридный** подход, комбинируя оба.

Гибридный подход Twitter

Twitter использует **гибридный fan-out**: Push для обычных пользователей, Pull для celebrities (>10K followers).

**Почему 10K?** Это баланс: 99% пользователей имеют <10K followers. Celebrity pull добавляет ~10ms latency, что приемлемо.

Хранение Timeline в Redis

Pre-computed timelines хранятся в **Redis Sorted Sets**. Score = timestamp, value = tweet_id.

**Только tweet_id!** Timeline хранит ID, не полные твиты. Гидратация (fetch full tweet) происходит при чтении.

Data Model и Storage

Twitter использует разные базы данных для разных access patterns: SQL для твитов, Cassandra для follow graph, Redis для timelines.

**Денормализация**: followers и following - две таблицы для одних данных. Разные access patterns = разные оптимизации.

Ключевые решения Twitter Design

• **Hybrid Fan-out**: Push для <10K followers, Pull для celebrities
• **Pre-computed Timelines**: Redis Sorted Sets (tweet_id only)
• **Polyglot Persistence**: MySQL (tweets), Cassandra (graph), Redis (timelines)
• **Sharding**: by user_id для всех stores
• **Async Processing**: Kafka для fan-out, notifications, analytics
• **Celebrity Optimization**: Pull on read добавляет ~10ms, но избегает 100M writes

Связанные темы

Twitter design использует многие паттерны

• Message Queue — Kafka для async fan-out
• Case Study: YouTube — Следующий case study - video streaming
• Caching — Redis для timeline storage

Вопросы для размышления

• Если порог celebrity = 10K followers, что происходит с follower count = 9999 → 10001 в момент перехода? Какой механизм должен обрабатывать миграцию?
• Каков худший случай latency timeline read при hybrid fan-out, и какие компоненты системы определяют этот worst case?
• Twitter добавил алгоритмический timeline (For You) поверх chronological. Как это меняет fan-out и storage стратегию?

Связанные уроки

• sd-13-url-shortener — Базовые паттерны масштабирования перед сложной соцсетью
• sd-09-message-queue — Fan-out через message queue для доставки твитов в ленты
• sd-07-caching — Celebrity timelines кэшируются отдельно из-за fan-out проблемы
• db-17-nosql-overview — NoSQL для timelines: строки = пользователи, колонки = твиты
• dist-14-sharding