Шаблон для system design собеса

1. Уточнение требований

 • Функциональные требования: Какие задачи решает система? (CRUD-операции, аналитика в реальном времени и т. д.)

 • Нефункциональные требования: DAU/MAU, кол-во взаимодействий с системой в сутки, пропорция read/write

 • Приблизительные вычисления:

  - Рассчитать RPS для понимания нагрузки (read/write)

  - Посчитать storage системы + retention policy

  - Закладываем peak multiplier для RPS, а также replication (X2-X3) для storage

 • Геораспределенность

 • Сезонность

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

 • Выделяем домены, чтобы было понимание, какие части системы будут общие, а какие уникальные

- Про домены можешь прочитать в этом ТГ посте

 • Поток данных от клиента к серверу:

  - Клиент → geoDNS → ДЦ

 • Примеры API

- Частые ошибки при проектировании API можешь глянуть в этом посте

 • Модель консистентности в системе и отдельных модулях 

Все это делаем на уровне C2. Если плохо разбираешься в C4, то смотри этот пост

Далее начинается более детальная проработка каждого домена в системе

3. Какой сервис/сервисы будем выделять?

- Не всегда нужны микросервисы. Если плаваешь в данной теме, то глянь цикл постов про это

4. База данных и хранение данных

 • Какие типы хранилища могут подойти к нашим сервисам и почему?

 • Как будем улучшать performance работы с данными

5. Балансировка внутри кластера (до сервисов и между сервисами)

 • Типы балансировщиков

  - Round-robin, sticky sessions, weighted LB и др.

 • Выбор Load Balancer-а

  - Простая балансировка → Nginx.

  - Продвинутая балансировка → HAProxy (гибкость маршрутизации, метрики).

  - API Gateway → Kong (авторизация, rate limiting, API-аналитика).

6. Прорабатываем межсервисное взаимодействие и надежность

 • Какие виды интеграций между сервисами и почему. Какие у них могут быть проблемы

 • Что если смежный сервис недоступен - fallbacks

 • Как нам защититься от резкого наплыва запросов на наш сервис

 • Какие способы оптимизации работы (паттерны по типу CQRS)

Глянь ряд полезных паттернов для масштабирования в этом посте

7. Мониторинг и алерты

 • Технический мониторинг

  - Threads

  - CPU, RAM, GC

  - DB connections, query time, transactions time

 • Бизнес-мониторинг

  - Кол-во заявок

  - RPS

 • Алерты

  - Пороговые значения для ошибок, RPS, времени ответа.

8. Дополнительные аспекты

 • CDN

 • Безопасность (JWT, OAuth).

9. Раскатка приложения: как будем масштабироваться и понимать, что все окей