Как решать System Design? На примере проектирования сервиса бесконечной персональной ленты

Статья описывает пошаговое проектирование сервиса персональной ленты подписок (упрощённый ***gram) для System Design интервью с нагрузкой 30 тыс. RPS на чтение и 1 тыс. RPS на запись.

Основные этапы проектирования

Авторы выделяют стандартный процесс:

• сбор требований (сущности вроде постов, подписок, ленты; функционал создания постов, пагинации, подписки; нефункционал — 30 млн DAU, SLA 2-3 сек),
• расчёты объёмов (43 ПБ картинок, 69 ТБ метаданных за 2 года, доминирование чтения),
• API (курсорная пагинация GET /v1/feed, POST /v1/post).

Архитектурные решения

Ключевой выбор — гибридная fan-out модель:

• push (fan-out-on-write) для обычных авторов в Redis-ленты подписчиков,
• pull (fan-out-on-read) для инфлюенсеров (>100 тыс. подписчиков) из отдельного кэша.
• Сервисы:
  • Image Service (S3 с двухэтапной загрузкой, CDN),
  • Post Service (PostgreSQL),
  • Feed Service (Redis, ~690 ГБ),
  • Relation Service (Neo4j или ScyllaDB для графа подписок).
  • События через Kafka для асинхронности.

Масштабирование

Load Balancer, DNS-балансировка по регионам, репликации, шардинг; решение проблем вроде «осиротевших» файлов (TTL в S3) и нагрузки от инфлюенсеров (метки в ленте вместо полных постов).