Real-Time Backend
Chat - media и файлы
Пользователь Telegram отправляет 4K видео 2GB в группу. Через секунду у всех участников появился thumbnail. Как?
- **WhatsApp** шифрует 100 млрд медиа-сообщений в день: сервер Meta хранит зашифрованные blob без ключей - юридически не может предоставить контент
- **Telegram** использует параллельный chunked upload (MTProto): 2GB файл разбивается на 512KB чанков и грузится по всем доступным каналам одновременно
- **Discord** генерирует thumbnails асинхронно: сообщение появляется мгновенно, thumbnail добавляется через WebSocket event через 1-3 секунды
- **iCloud Photos** (используется в iMessage) хранит медиа с E2E encryption в iCloud - Apple не имеет ключей и не может выполнить запросы правоохранителей
Resumable upload: загрузка без потерь
Загрузка медиафайлов через обычный POST-запрос ломается при нестабильном соединении: 95% видео загружено, сеть пропала - начинай заново. WhatsApp и Telegram используют resumable upload: загрузка разбивается на чанки, каждый подтверждается сервером.
Telegram использует собственный MTProto upload API: файл делится на 512KB чанков, каждый загружается параллельно с уникальным `part_id`. Сервер собирает их в правильном порядке. Это позволяет использовать все доступные каналы одновременно.
- Инициализировать upload session: получить ID и URL для загрузки
- Разбить файл на чанки (512KB - 5MB в зависимости от протокола)
- Загружать с текущего offset (HEAD запрос при возобновлении)
- После полной загрузки - сервер собирает и обрабатывает файл
Пользователь загружает видео 500MB. На 80% соединение прервалось. При возобновлении что делает клиент через TUS protocol?
Thumbnails: мгновенный preview
Thumbnail появляется мгновенно ещё до полной загрузки изображения. WhatsApp отправляет blurhash (32-байтная строка описывающая цветовое размытие) вместе с сообщением - клиент рендерит placeholder без скачивания файла.
Discord генерирует thumbnails асинхронно в отдельном воркере: сообщение с изображением появляется мгновенно, placeholder заменяется реальным thumb через WebSocket event `attachment_update` через 1-3 секунды.
Blurhash - это строка ~30 символов кодирующая размытое представление изображения. Telegram отправляет blurhash вместе с messageId - клиент рендерит цветной blur без единого HTTP-запроса, затем лениво грузит реальный thumbnail.
Telegram показывает размытый цветной placeholder вместо фото ещё до его загрузки. Откуда берётся информация для placeholder?
CDN доставка медиа: latency и стоимость
Медиафайлы чата нельзя раздавать с одного сервера: пользователь в Токио не должен ждать пока файл приедет из Амстердама. CDN решает это через edge nodes, но у чат-приложений есть специфика: файлы приватные и требуют авторизации.
WhatsApp хранит медиа на Zuck-серверах через Meta's internal CDN. После удаления переписки файлы удаляются через 30 дней - это компромисс между storage cost и UX при восстановлении. Telegram хранит медиа бессрочно для всех платных пользователей.
- Signed URL с TTL: клиент получает временный URL от API, CDN проверяет подпись
- CDN edge cache: популярные публичные медиа кешируются, приватные - только private cache
- Стриминг видео: Range запросы позволяют начинать воспроизведение до полной загрузки
- Дедупликация: один файл отправленный в 1000 чатов хранится один раз (hash-based dedup)
Фото в приватном чате доступно только участникам. Как CDN должен это контролировать?
E2E encryption: шифрование без доступа сервера
End-to-end encryption (E2E) означает что только отправитель и получатель могут прочитать сообщение - сервер видит только зашифрованный blob. Signal Protocol (используется в WhatsApp, Signal, Facebook Messenger) строится на трёх типах ключей.
WhatsApp шифрует 100 млрд сообщений в день через Signal Protocol. Сервер Meta видит только metadata: кто кому написал, когда, размер файла. Суды и спецслужбы неоднократно запрашивали доступ к перепискам - Meta отвечает что технически не может их предоставить.
Медиафайлы в WhatsApp шифруются отдельным ключом (media encryption key) от текстовых сообщений. Ключ передаётся внутри зашифрованного текстового сообщения. Сервер хранит зашифрованный медиафайл, но не имеет ключа для расшифровки.
HTTPS шифрует медиафайлы в чате - этого достаточно для приватности
HTTPS шифрует транспорт (от клиента до сервера), но сервер видит файл в открытом виде. E2E шифрует на устройстве отправителя - сервер получает и хранит зашифрованный blob который не может прочитать
Transport-level encryption (TLS/HTTPS) защищает от man-in-the-middle на сети, но не от самого сервера или его компрометации. E2E - единственный способ гарантировать что даже провайдер сервиса не имеет доступа к контенту
При E2E encryption медиафайла на CDN хранится зашифрованный blob. Кто владеет ключом для расшифровки?
Итоги
- **Resumable upload**: файл разбивается на чанки с подтверждением сервером - обрыв не требует начинать заново
- **Blurhash**: 30-байтная строка кодирует цветовой blur изображения - клиент рендерит placeholder без HTTP-запросов
- **E2E encryption**: медиаключ шифруется публичным ключом получателя - сервер хранит blob без возможности расшифровки
Связанные темы
Медиа в чате объединяет несколько слоёв инфраструктуры:
- CDN архитектура — Edge delivery и кеширование для низкой latency доставки медиа
- Signal Protocol — Криптографический протокол лежащий в основе E2E в WhatsApp и Signal
- Chat история и доставка — Медиафайлы - часть общего жизненного цикла сообщений
Вопросы для размышления
- Telegram хранит медиа бессрочно, WhatsApp удаляет через 30 дней. Какие архитектурные trade-offs это создаёт?
- Как реализовать поиск по содержимому чата если все сообщения зашифрованы E2E?
- При дедупликации медиа по хешу: если один пользователь отправил файл, другой может получить его URL. Как это совместить с E2E?