Источник
Александр Поломодов
Подход основан на наработках Александра для проведения System Design интервью в российском бигтехе
Долгосрочная подготовка к System Design Interview — это не заучивание готовых ответов, а развитие архитектурного мышления. В этой главе мы подробно разберём, какие навыки нужны на каждом этапе интервью и какие ресурсы помогут их развить.
Ключевая идея
Пойдём по 7 этапам System Design интервью и для каждого рассмотрим: что нужно знать и уметь, какие книги и ресурсы изучить, и какие практические навыки отработать.
Этап 1: Формализация требований
На этом этапе важнее всего уметь задавать правильные вопросы, чтобы уточнить что входит в scope задачи, а что можно благополучно вынести за скобки. Нужно уметь собирать функциональные требования в виде сценариев и определять нефункциональные характеристики.
Что нужно уметь
- Выяснять scope задачи через правильные вопросы
- Собирать функциональные требования как сценарии использования
- Определять нефункциональные требования (архитектурные характеристики)
- Расставлять приоритеты между конфликтующими требованиями
Подходы к сбору требований
Use Cases (UML)
Классический подход с actors, systems и списком сценариев. Для каждого сценария фиксируется happy path и exceptional flows — что позволяет понять как должен работать сценарий.
Actor → System → Scenario (Happy + Exceptional)User Story
Неформальный подход с точки зрения пользователя и полезной для него фичи.
Jobs to be Done (JTBD)
Фокус на результате и контексте — какую "работу" пользователь "нанимает" систему выполнить. Один и тот же продукт разные пользователи могут "нанимать" для разных целей.
Анализ нефункциональных требований
Для анализа архитектурных характеристик рекомендую изучить Architecture Tradeoff Analysis Method (ATAM). Ключевые концепции:
- Sensitivity points — решения, влияющие только на один атрибут качества
- Trade-off points — решения, влияющие на несколько атрибутов (улучшение одного ухудшает другой)
- Fit for purpose — система соответствует заявленным требованиям
- Fit for use — система удобна для реального использования
Связанная глава
API Gateway
Как оформить публичный API, обеспечить безопасность и маршрутизацию запросов.
Этап 2: Границы системы и Public API
На этом этапе нужно определить, как внешний мир будет взаимодействовать с системой. Это включает выбор протоколов, формата данных и понимание сетевого стека.
Что нужно знать
Сетевой стек
- TCP/IP и UDP — когда что использовать
- HTTP/1.1, HTTP/2, HTTP/3 — эволюция и trade-offs
- WebSocket — для real-time коммуникации
- DNS, CDN, Load Balancers
API стили
- REST — ресурсо-ориентированный подход
- gRPC — эффективный RPC с protobuf
- GraphQL — гибкие запросы от клиента
- Messaging — асинхронная интеграция
C4 Model для визуализации
Рекомендую освоить C4 Model — подход к визуализации архитектуры на разных уровнях:
C1
Context
Система и её окружение
C2
Container
Приложения и хранилища
C3
Component
Компоненты внутри контейнера
C4
Code
Классы и функции
Этап 3: Основные потоки данных
На этом этапе проектируются основные пути данных через систему — как информация записывается и читается, какие компоненты задействованы.
Write Path
Путь данных при записи — от клиента до персистентного хранилища.
- Валидация входных данных
- Write-ahead logging
- Синхронная/асинхронная запись
- Репликация и подтверждение
Read Path
Путь данных при чтении — от запроса до ответа клиенту.
- Кеширование (L1, L2, CDN)
- Чтение с реплик
- Pagination и streaming
- Materialized views
Нотации для описания потоков
- Sequence Diagram (UML) — последовательность сообщений между компонентами
- Activity Diagram (UML) — бизнес-процесс с ветвлениями и параллельными потоками
- BPMN — более формальная нотация для бизнес-процессов
- Data Flow Diagram — движение данных между процессами и хранилищами
Связанная глава
Путеводитель по базам данных
База для проектирования схем данных и выбора хранилищ.
Этап 4: Концептуальная схема данных
На этом этапе проектируется модель данных без привязки к конкретным технологиям. Определяются сущности, их атрибуты и связи между ними.
Stateful vs Stateless
Stateful компоненты
Хранят состояние между запросами. Сложнее масштабировать.
- Базы данных
- Кеши с персистентностью
- Message brokers
- Session stores
Stateless компоненты
Не хранят состояние. Легко масштабируются горизонтально.
- API серверы
- Workers
- Load balancers
- Gateways
Связанная глава
Learning Domain-Driven Design
Практический DDD: стратегический и тактический дизайн, контексты и события.
Domain-Driven Design
Для проектирования сложных доменов рекомендую изучить DDD. Ключевые концепции:
- Bounded Context — чёткие границы модели с единым языком внутри
- Aggregate — кластер объектов, образующих единицу консистентности
- Entity vs Value Object — объекты с идентичностью vs неизменяемые значения
- Domain Events — события, значимые для бизнеса
Этап 5: Выбор технологий
На этом этапе концептуальная схема превращается в реальную — выбираются конкретные технологии с учётом их trade-offs и failure domains.
Категории технологий
Базы данных
PostgreSQL
ACID, сложные запросы, JSON
MySQL
надёжность, репликация
MongoDB
документы, гибкая схема
Cassandra
высокая доступность, масштаб
Кеширование
Redis
структуры данных, pub/sub, персистентность
Memcached
простой key-value, multi-threading
Очереди сообщений
Kafka
высокая пропускная способность, replay
RabbitMQ
гибкая маршрутизация, AMQP
SQS
managed, serverless
Поиск
Elasticsearch
полнотекстовый поиск, аналитика
Meilisearch
простой, typo-tolerant
Failure Domains
Важно понимать
Для каждой технологии продумайте: что произойдёт при её отказе? Какой blast radius? Как система восстановится? Это показывает зрелость инженера на интервью.
Этап 6: Масштабирование
Когда базовая архитектура готова, нужно обсудить как система будет расти. Что произойдёт при увеличении нагрузки в 10x, 100x, 1000x?
Вертикальное масштабирование
Увеличение ресурсов одной машины (CPU, RAM, Disk).
- ✅ Просто реализовать
- ✅ Нет изменений в коде
- ❌ Ограничено размером машины
- ❌ Single point of failure
Горизонтальное масштабирование
Добавление новых инстансов системы.
- ✅ Практически безгранично
- ✅ Отказоустойчивость
- ❌ Сложнее в реализации
- ❌ Требует stateless дизайна
Техники масштабирования данных
- Партиционирование — разделение данных по ключу (user_id, region, time)
- Шардинг — распределение данных по нескольким независимым базам
- Консистентное хеширование — минимизация перераспределения при добавлении нод
- Репликация — копии данных для чтения и отказоустойчивости
- CQRS — разделение моделей чтения и записи
Этап 7: Продвинутые темы
Если осталось время, обсудите темы долгосрочной эксплуатации системы. Это показывает, что вы думаете не только о разработке, но и о production.
Observability
- Metrics (Prometheus, Grafana)
- Logs (ELK, Loki)
- Traces (Jaeger, Zipkin)
- SLI/SLO/SLA
Deployment
- Blue-green deployment
- Canary releases
- Feature flags
- Rollback strategies
Security
- Authentication & Authorization
- Encryption at rest/in transit
- API rate limiting
- Audit logging
Disaster Recovery
- RTO & RPO
- Backup strategies
- Failover automation
- Chaos engineering
Рекомендуемая литература
Для глубокого понимания системного дизайна рекомендуем изучать профессиональную литературу. Книги дают фундамент, который не устареет через год, и помогают понять принципы, а не просто запомнить готовые решения.
Часть 4: Обзор источников по System Design
Полная коллекция обзоров книг по распределённым системам, архитектуре, микросервисам, DDD и SRE — с ключевыми идеями и практическими выводами
Заключение
Долгосрочная подготовка — это марафон, а не спринт. Не пытайтесь прочитать всё за месяц. Вместо этого выберите 2-3 книги из списка и глубоко их изучите. Практикуйтесь на реальных проектах и mock интервью.
Главное — развивать архитектурное мышление, а не заучивать готовые решения. Интервьюер всегда может изменить условия задачи, и важно уметь адаптироваться.
В следующей главе рассмотрим тактики краткосрочной подготовки — что делать, если интервью уже через неделю.