Twitter/X

Функциональные требования

• Публикация твита — короткий текстовый пост, медиа и базовые взаимодействия.
• Домашняя лента — персональная лента твитов от аккаунтов, на которые подписан пользователь.
• Лента пользователя — все твиты конкретного автора в обратном хронологическом порядке.
• Подписка и отписка — управление графом подписок между аккаунтами.
• Лайки и ретвиты — базовые сигналы вовлечения.
• Поиск — поиск по твитам, аккаунтам и ключевым словам.
• Трендовые темы — быстрое определение всплесков обсуждения в реальном времени.
• Уведомления — упоминания, ответы, лайки и другие события вокруг аккаунта.

Нефункциональные требования

Для пользователя здесь критичны низкая задержка (latency) чтения и понятное окно обновления ленты. Абсолютная консистентность (consistency) не обязательна: новый твит может появиться у части подписчиков с небольшой задержкой, если это помогает удерживать систему стабильной.

• Масштаб: около 500M зарегистрированных пользователей и 200M DAU.
• Объём записи: порядка 500M новых твитов в сутки.
• Профиль нагрузки: чтений на порядки больше, чем записей, примерно 1000:1.
• Домашняя лента: ответ желательно удерживать в пределах 200 мс.
• Допустимая задержка появления: 5-10 секунд для обновления у части подписчиков приемлемы.
• Доступность: ориентир — 99.99%, при этом сервис должен переживать частичные сбои без массового отказа.
• Проблема популярных аккаунтов: публикация не должна останавливаться, если у автора десятки или сотни миллионов подписчиков.

Главная задача: сборка ленты

Главная архитектурная проблема Twitter/X — как собирать домашнюю ленту быстро и дёшево, когда почти каждый твит нужно показать многим подписчикам. Базовых стратегий две: либо использовать раздачу при записи (fanout-on-write) и заранее раскладывать твит по готовым лентам, либо выбрать раздачу при чтении (fanout-on-read) и собирать ленту по запросу из последних публикаций нужных аккаунтов.

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

На практике Twitter/X использует гибридную схему: для обычных аккаунтов работает раздача при записи, а для очень популярных авторов — раздача при чтении. Такой режим снижает цену раздачи по множеству получателей (fan-out) там, где публикация одного твита иначе взорвала бы систему по числу записей.

Архитектура кэша домашней ленты

Кэш домашней ленты нужен, чтобы самый частый путь чтения был дешёвым. Обычно публикация подтверждается быстро, а сама раскладка по кэшам уходит в очередь сообщений (message queue), чтобы не держать пользователя на тяжёлой фоновой работе.

# У каждого пользователя есть собственная домашняя лента в Redis
# Key: timeline:{user_id}
# Value: Sorted Set (score = timestamp, member = tweet_id)

ZADD timeline:12345 1705234567 "tweet_abc123"
ZADD timeline:12345 1705234890 "tweet_def456"

# Получение последних 100 твитов
ZREVRANGE timeline:12345 0 99

# Приближённая оценка объёма:
# 200M пользователей × 800 твитов × 8 байт = 1.28 TB
# С репликацией ×3 = около 4 TB Redis-кластера

Трендовые темы

Определение трендов — это уже потоковая обработка (stream processing): системе важно ловить всплеск обсуждения, а не просто абсолютное число твитов. Для компактного счёта хорошо подходит структура Count-Min Sketch (Count-Min Sketch), а скорость роста считать через скользящее окно (sliding window).

Формула скоринга трендов

# Упрощённая формула скоринга трендов Twitter

def calculate_trend_score(topic, current_window):
    # Текущая скорость: твиты в минуту за последние 5 минут
    current_count = count_in_window(topic, minutes=5)

    # Базовый уровень: среднее число твитов за 5 минут за последние 7 дней
    baseline_count = get_baseline(topic, days=7)

    # Во сколько раз тема растёт быстрее обычного
    if baseline_count > 0:
        velocity_ratio = current_count / baseline_count
    else:
        velocity_ratio = current_count * 10  # бонус для новой темы

    # Вес свежести: экспоненциальное затухание
    recency_weight = sum(
        tweet.weight * exp(-lambda * (now - tweet.timestamp))
        for tweet in current_window.tweets
    )

    # Буст от вовлечения
    engagement_score = (likes + retweets * 2 + replies * 3) / total_tweets

    # Финальный счёт
    score = velocity_ratio * recency_weight * (1 + log(engagement_score))

    # Фильтрация спама и ботов
    if unique_users_ratio < 0.3:  # слишком мало уникальных пользователей
        score *= 0.1  # сильный штраф

    return score

Ранжирование ленты

Современный Twitter/X опирается не только на хронологию, но и на ранжирование (ranking). Модель пытается предсказать вероятность вовлечения и поднять в ленте те твиты, которые пользователь с большей вероятностью прочитает, лайкнет или откроет.

Архитектура поиска

Поиск по твитам живёт в отдельном контуре: сначала новые документы попадают в оперативный индекс, а затем уплотняются в дисковые сегменты. На пользовательском пути система разбирает запрос, ищет по шардам параллельно и после этого сливает результаты.

Модель данных

Основное хранилище держит нормализованные сущности, а путь чтения опирается на денормализованные структуры в Redis и вспомогательные индексы для быстрых ответов.

# Базовые таблицы

tweets {
    tweet_id: UUID (Snowflake ID)
    user_id: UUID
    content: VARCHAR(280)
    media_urls: JSON
    created_at: TIMESTAMP
    reply_to_tweet_id: UUID (nullable)
    retweet_of_id: UUID (nullable)
    quote_tweet_id: UUID (nullable)
    like_count: INT
    retweet_count: INT
    reply_count: INT
}

users {
    user_id: UUID
    username: VARCHAR(15)
    display_name: VARCHAR(50)
    bio: VARCHAR(160)
    follower_count: INT
    following_count: INT
    is_verified: BOOLEAN
    is_celebrity: BOOLEAN  # follower_count > 10K
    created_at: TIMESTAMP
}

follows {
    follower_id: UUID
    followee_id: UUID
    created_at: TIMESTAMP
    PRIMARY KEY (follower_id, followee_id)
}

# Денормализованные структуры для чтения
user_timelines (Redis Sorted Set)
    Key: timeline:{user_id}
    Score: tweet_timestamp
    Member: tweet_id

# Твиты популярных аккаунтов
celebrity_tweets (Redis Sorted Set)
    Key: celebrity:{user_id}
    Score: tweet_timestamp
    Member: tweet_id

Генерация Snowflake ID

Twitter разработал Snowflake ID, чтобы получать уникальные и примерно сортируемые по времени идентификаторы без центрального координатора.

# Структура Snowflake ID (64 бита)
┌────────────────────────────────────────────────────────────────┐
│ 1 bit │   41 bits timestamp   │ 10 bits │    12 bits          │
│unused │   (milliseconds)      │machine  │   sequence          │
│       │   since epoch         │   ID    │   number            │
└────────────────────────────────────────────────────────────────┘

# Свойства:
# - Примерно сортируется по времени
# - Не требует центральной координации
# - 4096 ID в миллисекунду на машину
# - Хватает на десятки лет до переполнения

# Пример ID: 1605978261000000000
# Timestamp: 2020-11-21 12:31:01 UTC
# Machine: 42
# Sequence: 0

def generate_snowflake_id(machine_id, last_timestamp, sequence):
    timestamp = current_time_ms() - TWITTER_EPOCH

    if timestamp == last_timestamp:
        sequence = (sequence + 1) & 0xFFF  # 12 bits
        if sequence == 0:
            timestamp = wait_next_millis(last_timestamp)
    else:
        sequence = 0

    id = (timestamp << 22) | (machine_id << 12) | sequence
    return id, timestamp, sequence

Высокоуровневая архитектура

На верхнем уровне архитектура раскладывается на отдельные контуры публикации, чтения, поиска и трендов. Главное здесь — не смешивать их в одну универсальную цепочку, а дать каждому пути свою стоимость, свои кэши и свои режимы деградации.

Подсказки для интервью

Дополнительные ресурсы