Как проектировать систему с высокой нагрузкой (Instagram, Twitter на высоком уровне)?

Сначала уточнить требования

Нужно определить основные сценарии: публикация поста, загрузка медиа, просмотр feed, лайки, комментарии, подписки, поиск, уведомления и прямые сообщения. Затем уточняют DAU, пиковый RPS, read/write ratio, размер медиа, требования к latency, consistency, retention и географию пользователей.

Базовая архитектура

Clients
  |
CDN / WAF / Load Balancer
  |
API Gateway
  |
+------------------------------------+
| User | Post | Feed | Media | Search|
+------------------------------------+
  |          |            |
Cache      Databases     Object Storage
  |          |            |
Redis       Shards       CDN
  |
Message Broker / Event Stream
  |
Notifications / Feed workers / Analytics

Разделение данных

• профили и отношения подписок — отдельное масштабируемое хранилище;

• посты и метаданные — шардированное хранилище по user ID или post ID;

• медиа — object storage, а доставка через CDN;

• feed cache — Redis или специализированное хранилище лент;

• поиск — отдельный индекс, например Elasticsearch/OpenSearch;

• события — очередь или event stream для асинхронной обработки.

Fan-out on write и fan-out on read

При fan-out on write новый пост сразу добавляют в precomputed feed подписчиков. Чтение feed становится быстрым, но публикация аккаунта с миллионами подписчиков становится очень дорогой. При fan-out on read feed собирается во время чтения из постов подписок; публикация проще, но чтение тяжелее.

На практике используют гибрид: для обычных пользователей — fan-out on write, для знаменитостей с огромной аудиторией — fan-out on read с последующим объединением результатов.

Consistency и асинхронность

Не все операции требуют строгой консистентности. Лайки, счётчики и feed часто допускают eventual consistency. Но платежи, права доступа, удаление данных и уникальные пользовательские имена могут требовать более строгих гарантий. Асинхронные действия нужно передавать через очередь с идемпотентными consumer-ами и retry policy.

Надёжность и эксплуатация

• stateless сервисы и горизонтальное масштабирование;

• кэширование, cache invalidation и защита от cache stampede;

• rate limiting, abuse detection и защита upload-потока;

• multi-AZ, backup, disaster recovery и контролируемый failover;

• метрики, логи, tracing, SLO и нагрузочное тестирование;

• деградация функциональности при сбоях, например временное отключение рекомендаций.

Как ответить на собеседовании

Я начинаю с требований и расчёта read/write нагрузки. Дальше разделяю платформу на stateless-сервисы, кэш, шардированные хранилища, object storage с CDN и event stream. Для социальной ленты использую гибрид fan-out on write и fan-out on read, учитывая проблему celebrity users. Критично также обсудить consistency, идемпотентность, observability, rate limit и стратегию деградации.