System Design Space

    Глава 5

    Обновлено: 15 февраля 2026 г. в 09:21

    Подходы к проведению интервью по проектированию

    Прогресс части0/11

    7-шаговый фреймворк System Design Interview и список книг для глубокого изучения.

    Статья

    Как готовиться к System Design Interview

    Подробная статья о подготовке к System Design интервью

    Перейти на сайт

    Вопрос о том, как подготовиться к System Design Interview встречался часто. Ответ сильно зависит от времени на подготовку. В этой главе мы рассмотрим долгосрочный подход к развитию архитектурного мышления и системный фреймворк прохождения интервью.

    7-шаговый фреймворк System Design Interview

    Прежде чем говорить о подготовке, важно понять структуру самого интервью. Мы используем фреймворк из 7 шагов, который помогает системно подходить к проектированию любой системы:

    1

    Название задачи

    • Базовый контекст
    • Функциональные требования
    • Нефункциональные требования
    2

    Формализация

    • Основные функции
    • Ключевые -ilities
    • Базовый sizing: пользователи, запросы...
    3

    Границы системы

    • Use cases
    • Public API
    • Интеграционные контракты
    4

    Workflow и компоненты

    • Happy path
    • Масштабирование под NFR
    • Corner cases и отказы
    5

    Концептуальная схема

    • Public API в схеме
    • Компоненты с классами (K/V, RDBMS)
    • Модели данных
    • Stateful/Stateless
    6

    Выбор технологий

    • Конкретные технологии
    • Расчёт мощностей
    • Failure domains
    7

    Дополнительные вопросы

    • Observability
    • Security
    • Deployment
    • Advanced topics

    Теперь давайте рассмотрим каждый шаг подробнее и разберём, как к нему готовиться.

    Связанная глава

    Software Requirements (Wigers)

    Уровни требований, техники выявления, приоритизация и управление изменениями.

    Читать главу

    Шаг 1: Формализация требований

    На этом этапе вы проясняете функциональные требования (что система должна делать) и нефункциональные требования (как она должна это делать). Это критически важный шаг, потому что без него вы рискуете спроектировать не ту систему.

    Нефункциональные требования (-ilities)

    • High Availability — система должна быть доступна 99.9%+ времени
    • Scalability — система должна справляться с ростом нагрузки
    • Performance — latency p99 < 100ms или другой SLO
    • Durability — данные не должны теряться
    • Consistency — eventual vs strong consistency — осознанный выбор
    • Fault Tolerance — система переживает отказы компонентов

    Ключевой совет

    Всегда уточняйте у интервьюера: какие характеристики критичны? Нельзя оптимизировать всё сразу — выбирайте приоритеты. Например, для банковской системы consistency важнее latency, а для ленты соцсети — наоборот.

    Связанная глава

    API Gateway

    Контракты API, маршрутизация, лимиты и контроль доступа на внешнем периметре.

    Читать главу

    Шаг 2: Границы системы (Public API)

    Определите, как внешний мир будет взаимодействовать с вашей системой. Это контракт между системой и её клиентами.

    REST API

    Стандартный выбор для публичных API. Хорошо подходит для CRUD операций.

    RPC (gRPC)

    Эффективен для внутренних сервисов. Строгие контракты через protobuf.

    Messaging

    Для асинхронной интеграции. Kafka, RabbitMQ, SQS.

    Связанная глава

    Event-Driven Architecture

    Потоки данных, события, retry и компенсации в распределённых сценариях.

    Читать главу

    Шаг 3: Core Flows и компоненты

    Нарисуйте основные потоки данных в системе. Начните с happy path — основного сценария использования, а затем добавьте exceptional flows.

    • Read path — как данные читаются из системы (кеши, реплики)
    • Write path — как данные записываются (очереди, журналирование)
    • Happy path — основной успешный сценарий
    • Exceptional flows — обработка ошибок, ретраи, fallbacks

    Связанная глава

    Путеводитель по базам данных

    Концептуальное моделирование данных и выбор хранилищ под сценарии нагрузки.

    Читать главу

    Шаг 4: Концептуальная схема данных

    Спроектируйте модель данных, не привязываясь пока к конкретным технологиям. Определите основные сущности и связи между ними.

    Stateful компоненты

    • Базы данных
    • Кеши с персистентностью
    • Очереди сообщений
    • Файловые хранилища

    Stateless компоненты

    • API серверы
    • Workers/Processors
    • Load balancers
    • Gateways

    Связанная глава

    Database Selection Framework

    Практический фреймворк выбора СУБД с учетом trade-offs и требований.

    Читать главу

    Шаг 5: Реальная схема (технологии)

    Теперь выбираем конкретные технологии. Важно понимать trade-offs каждого решения и уметь обосновать свой выбор.

    1Базы данных: PostgreSQL vs MySQL vs MongoDB vs Cassandra
    2Кеширование: Redis vs Memcached vs local cache
    3Очереди: Kafka vs RabbitMQ vs SQS vs Redis Streams
    4Search: Elasticsearch vs Solr vs Meilisearch
    5Object Storage: S3 vs GCS vs MinIO

    Failure Domains

    Обязательно продумайте, что произойдёт при отказе каждого компонента. Какой blast radius? Как система восстановится? Это показывает зрелость инженера.

    Связанная глава

    Принципы проектирования масштабируемых систем

    Вертикальное/горизонтальное масштабирование, шардирование и узкие места.

    Читать главу

    Шаг 6: Масштабирование

    Когда базовая архитектура готова, обсудите как система будет масштабироваться при росте нагрузки в 10x, 100x, 1000x.

    • Вертикальное масштабирование — увеличение ресурсов одной машины (проще, но ограничено)
    • Горизонтальное масштабирование — добавление новых инстансов (сложнее, но безгранично)
    • Партиционирование данных — разделение данных по ключу (user_id, region, time)
    • Шардинг — распределение данных по нескольким базам
    • Консистентное хеширование — минимизация перераспределения при добавлении нод

    Связанная глава

    Observability & Monitoring Design

    Глубокий разбор logs/metrics/traces и практик алертинга.

    Читать главу

    Шаг 7: Advanced Topics

    Если осталось время, обсудите темы долгосрочной эксплуатации системы:

    • Observability — metrics, logs, traces — как понять, что система здорова
    • Alerting — на что алертить и как не утонуть в шуме
    • Deployment — blue-green, canary, feature flags
    • Disaster Recovery — RTO/RPO, backup strategies, failover
    • Security — authentication, authorization, encryption at rest/in transit

    Связанная глава

    Оценка интервью и вариация сложности

    Как интервьюер калибрует уровень и по каким критериям оценивается решение.

    Читать главу

    Советы для успешного прохождения интервью

    Я собрал короткий список советов, который, как мне кажется, повышает эффективность прохождения интервью и вероятность того, что вы сможете показать свои лучшие стороны:

    • Помнить о времени — время интервью обычно ограничено часом и за него надо успеть многое обсудить. Именно поэтому не стоит закапываться в какие-то детали, а контролировать тайминг и двигаться по решению задачи
    • Не начинать проектировать сразу — важно четко понять задачу и только тогда начинать ее решать. Если у вас есть вопросы после прочтения условий, то лучше сначала получить на них ответы, иначе можно начать не ту задачу, что вас попросили
    • Делиться своими размышлениями — этот тип собеседования нужен для того, чтобы понять как вы решаете сложные задачи и как мыслите при их решении. Если вы будете преимущественно молча рисовать схему и изредка рассказывать что вы нарисовали, то интервьюер не поймет всей глубины вашей задумки
    • Проявлять самостоятельность в проектировании — это открытое интервью, где кандидат может проявить свои сильные стороны и показать как он проектирует. Но если интервьюеру придется вести кандидата по задаче, задавая структуру и помогая с решением, то это не добавит очков кандидату
    • Реагировать на наводящие вопросы — обычно интервьюер такими вопросами пытается навести кандидата на правильные мысли, когда он забуксовал
    • Говорить уверенно о том, что знаешь — не стоит говорить о том, о чем только смутно слышал, так как интервьюер может поинтересоваться деталями и тогда кандидату придется краснеть
    • Подготовить вопросы к интервьюеру — на случай, если для них останется время — это показывает то, что вам интересно узнать про компанию и происходящее в ней

    Связанная глава

    Рекомендации по подготовке (long term)

    Детальный long-term план развития навыков по каждому шагу интервью.

    Читать главу

    Долгосрочная подготовка: что читать

    Для глубокого понимания системного дизайна рекомендуем изучать профессиональную литературу. Книги дают фундамент, который не устареет через год, и помогают понять принципы, а не просто запомнить готовые решения.

    Часть 4: Обзор источников по System Design

    Полная коллекция обзоров книг по распределённым системам, архитектуре, микросервисам, DDD и SRE — с ключевыми идеями и практическими выводами

    Заключение

    Долгосрочная подготовка к System Design Interview — это развитие инженерного мышления, а не заучивание готовых ответов. Читайте книги, изучайте архитектуры реальных систем, практикуйтесь на mock интервью.

    Используйте 7-шаговый фреймворк как структуру для любого интервью. Он поможет не потеряться и показать системный подход к проектированию.

    В следующей главе мы рассмотрим тактики краткосрочной подготовки — что делать, если интервью уже через неделю.

    Источники и дополнительные материалы