Книга Stanley Chiang сильна не тем, что обещает быстрый секрет успеха, а тем, что собирает подготовку в очень практичный маршрут: базовые концепции, типовые компоненты, семишаговый ритм ответа и большой набор задач. Эта глава как раз показывает, почему материал ощущается прикладным и хорошо организованным.
В реальной инженерной практике она полезна тем, что дисциплинирует движение по задаче под давлением времени: сначала понять границы системы, затем собрать модель данных и оценки нагрузки, после этого выбрать архитектуру и только потом уходить в узкие места и компромиссы.
Для подготовки к интервью эта глава особенно ценна тем, что переводит теорию в режим повторяемой тренировки: семь шагов дают устойчивый ритм ответа, а шестнадцать практических кейсов помогают увидеть, где разваливается структура, где не хватает базы и какие детали ещё не держатся уверенно.
Практическая польза главы
Семь шагов ответа
Даёт повторяемый ритм прохождения кейса под давлением времени и переключений контекста.
Управление глубиной
Помогает вовремя остановиться на каркасе и углубляться только в действительно критичные узлы.
Неочевидные кейсы
Расширяет кругозор задачами за пределами стандартного набора: от геопоиска до межпланетных систем.
Репетиция интервью
Помогает перевести теорию в повторяемую тренировку с понятным прогрессом по качеству ответа.
Введение
Источник
Оригинальная статья
Обзор книги Stanley Chiang в блоге Code of Architecture
Hacking the System Design Interview
Авторы: Stanley Chiang
Издательство: Independently published, 2022
Объём: —
Разбор книги Stanley Chiang: семишаговый ритм ответа, 16 практических кейсов и советы по структуре архитектурного разговора.
Личное мнение
Эта книга показалась мне интереснее, чем книга Alex Xu. Здесь лучше собран путь от базы к практике: меньше ощущения разрозненных примеров и больше дисциплины в том, как именно разворачивать архитектурный ответ.
Главная сила книги в том, что она превращает в повторяемый маршрут: сначала договориться о границах, потом собрать каркас решения и только после этого уходить в детали. За счёт этого книга полезна и как учебный материал, и как опорный сценарий для самостоятельной репетиции ответов.
Связанная глава
Зачем читать книги для подготовки к интервью по системному дизайну
Карта источников: как комбинировать книги, курсы и практические кейсы в единый план подготовки.
Структура книги
Книга начинается с вводного блока о формате архитектурного раунда, а затем раскладывает подготовку на три больших слоя: базовые идеи, общие инфраструктурные компоненты и набор практических задач.
1. Интервью по системному дизайну
Как устроен архитектурный раунд, чего от него ждут и как использовать книгу как план подготовки, а не как набор разрозненных решений.
2. Базовые концепции
Терминология и фундаментальные принципы, на которые автор опирается во всех дальнейших кейсах:
3. Ключевые компоненты
Инфраструктурные блоки, которые затем снова появляются в практических задачах:
4. Практические задачи по системному дизайну
Семишаговый фреймворк ответа, методы грубой оценки, визуализация архитектуры и 16 практических задач для тренировки под тайминг интервью.
Связанная глава
Фреймворки прохождения интервью
Дополнительные структуры ответа на архитектурном раунде и практики управления временем.
Семишаговый фреймворк интервью
Автор предлагает не просто список подсказок, а последовательность, которая удерживает разговор в правильном порядке даже под давлением времени.
В этой части книга постоянно возвращается к , к , и к метрикам вроде , , и . За счёт этого фреймворк не превращается в пустой ритуал, а опирается на измеримые ограничения.
Понять задачу и границы системы
Здесь важно не бросаться рисовать архитектуру, а сначала договориться о сценариях, ограничениях и масштабе. Этот шаг задаёт глубину всего дальнейшего разговора.
Ключевые вопросы:
- Какие основные сценарии должна поддерживать система?
- Какие объёмы нагрузки и рост аудитории нужно держать в голове?
- Есть ли ограничения по времени ответа, бюджету или домену задачи?
Определить модель данных
На втором шаге автор предлагает быстро зафиксировать, какие сущности живут в системе, какие сообщения циркулируют между компонентами и где проходит граница между транзакционными и производными данными.
Обмен сообщениями
Форматы обмена данными между компонентами системы
Хранилище данных
Схема данных и выбор типа хранилища
Оценить нагрузку на высоком уровне
Здесь мы не ищем точность до последнего знака, а быстро понимаем порядок величин для трафика, хранилища и сетевого канала.
Что оцениваем:
- Ежедневную и ежемесячную активную аудиторию
- Количество запросов в секунду (QPS)
- Объём хранимых данных
- Пропускная способность сети
Согласовать верхнеуровневую архитектуру
После уточнения требований и оценки масштаба нужно быстро собрать общий каркас решения и согласовать его с интервьюером. Без этого слишком легко углубиться не туда.
Обязательно получите подтверждение от интервьюера, что вы на правильном пути, прежде чем углубляться в детали.
Углубиться в критичные детали
После согласования каркаса стоит выбирать только самые рискованные или самые дорогие по последствиям узлы и разбирать именно их.
На что обратить внимание:
- Детали реализации ключевых компонентов
- Алгоритмы и структуры данных
- Обработка пограничных сценариев
- Выбор конкретных технологий
Определить API и интерфейсы
Когда общий каркас и критичные детали уже понятны, полезно явно проговорить внешние и внутренние интерфейсы, чтобы ответ не висел в воздухе.
Внешние API
REST, GraphQL, gRPC эндпоинты для клиентов
Внутренние интерфейсы
Контракты между микросервисами
Обсудить узкие места и рост нагрузки
Финальный шаг нужен, чтобы показать зрелость решения: где оно упрётся в первую очередь, как будет деградировать и что мы будем делать по мере роста нагрузки.
Темы для обсуждения:
- Узкие места и способы их устранения
- Единственные точки отказа
- Масштабирование под рост нагрузки
- Мониторинг и оповещения
Практические задачи
Ниже полный набор из 16 задач в формате рабочей шпаргалки: для каждой темы выделены фокус, вопросы на уточнение, архитектурные решения и типичные риски.
Сильная сторона этого блока в том, что книга не ограничивается привычными чатами и лентами, а заставляет связывать между собой , , , , и .
По мере роста сложности в кейсах появляются , , , , , , и .
В самых необычных задачах книга добирается до , , , , , , , и .
Сокращатель ссылок
URL Shortener
Практический кейс про стратегию коротких идентификаторов, путь перенаправления и защиту от злоупотреблений.
Фокус: Короткие ссылки, быстрые перенаправления и защита от коллизий.
Сервис создаёт короткие адреса для маркетинговых и пользовательских сценариев, а основная нагрузка приходится на чтение и мгновенное перенаправление.
Что уточнить на интервью
- •Каково соотношение чтений и записей и какое время ответа на перенаправление считается допустимым?
- •Нужны ли пользовательские алиасы, время жизни ссылок и возможность отключать их?
- •Насколько быстро должна появляться статистика по кликам?
Архитектурный фокус
- •Генерация коротких идентификаторов и защита от коллизий.
- •Кэширование популярных ссылок и ускорение пути перенаправления на краю сети.
- •Проверка URL, чёрные списки и защита от злоупотреблений.
Типичные риски
- •Перебор предсказуемых идентификаторов.
- •Горячие ключи на вирусных ссылках.
Чат
Chat System
Практический кейс про транспорт, гарантии доставки и онлайн-статус пользователей.
Фокус: Обмен сообщениями в реальном времени, онлайн-статус и доставка офлайн.
Чат должен поддерживать личные и групповые диалоги, стабильную доставку сообщений и синхронизацию между устройствами.
Что уточнить на интервью
- •Нужен ли строгий порядок сообщений внутри диалога?
- •Какие требования к онлайн-статусу и индикатору набора сообщения?
- •Нужны ли отметки о прочтении, вложения и история на нескольких устройствах?
Архитектурный фокус
- •Постоянные соединения для мгновенной доставки и отдельный резервный канал уведомлений.
- •Очереди сообщений и фоновые обработчики для надёжной доставки.
- •Хранение истории и синхронизация между устройствами.
Типичные риски
- •Долгоживущие соединения усложняют масштабирование.
- •Потеря сообщений при переключении без устойчивой очереди.
Поисковые подсказки
Search System
Кейс из темы 3 про индексацию, извлечение результатов и жёсткие требования ко времени ответа.
Фокус: Подсказки по мере ввода с минимальной задержкой.
Система должна подсказывать варианты на каждый новый символ и выдерживать всплески поисковой активности.
Что уточнить на интервью
- •Нужна ли персонализация подсказок или достаточно общего списка популярных вариантов?
- •Как часто обновляется модель частотности запросов?
- •Какой набор языков/локалей поддерживается?
Архитектурный фокус
- •Префиксное дерево и заранее посчитанные популярные варианты для каждого префикса.
- •Отдельный конвейер обновления статистики запросов.
- •Кэширование самых популярных префиксов на прикладном уровне.
Типичные риски
- •Медленное обновление статистики портит актуальность подсказок.
- •Неравномерно популярные префиксы создают перекос нагрузки.
Лента новостей
Twitter/X
Практический кейс социальной ленты: стратегии раздачи, кэширование и работа с горячими аккаунтами.
Фокус: Персональная лента, ранжирование и раздача новых публикаций.
Лента должна быстро обновляться при высокой активности аудитории и поддерживать персонализацию без потери предсказуемости.
Что уточнить на интервью
- •Какой уровень сервиса нужен для публикации поста и открытия ленты?
- •Нужна ли строгая хронология или лента сразу строится с ранжированием?
- •Какой разброс по числу подписок и активности у самых крупных аккаунтов?
Архитектурный фокус
- •Раздача публикаций заранее, при чтении или гибридная схема.
- •Несколько уровней кэша для таймлайна, объектов и счётчиков.
- •Асинхронная обработка медиа и сигналов вовлечённости.
Типичные риски
- •Эффект знаменитости перегружает путь публикации.
- •Кэш ленты начинает расходиться с основным источником данных.
Веб-краулер
Web Crawler
Кейс из темы 3 про очередь обхода, удаление дублей и бережную работу с внешними доменами.
Фокус: Масштабный обход веб-графа с контролем качества индекса.
Краулер должен устойчиво обходить миллиарды URL, не собирать дубликаты и бережно вести себя по отношению к внешним сайтам.
Что уточнить на интервью
- •Какой объём обхода в сутки и какая свежесть индекса действительно нужна?
- •Какие типы контента/файлов нужно извлекать?
- •Нужно ли строго соблюдать robots.txt и ограничения по доменам?
Архитектурный фокус
- •Очередь обхода с приоритетами и отдельными правилами вежливого опроса доменов.
- •Набор загрузчиков, удаление дублей и канонизация URL.
- •Конвейер парсинга и постановки новых ссылок в обход.
Типичные риски
- •Ловушки краулера и бесконечные графы ссылок.
- •Слишком агрессивный обход приводит к блокировкам.
Ограничитель запросов
Rate Limiter
Кейс из темы 3 про алгоритмы лимитирования, распределённые счётчики и поведение под всплесками нагрузки.
Фокус: Контроль трафика и защита API от перегрузки.
Этот компонент должен защищать разные сервисы от перегрузки и при этом не мешать нормальному трафику во время всплесков.
Что уточнить на интервью
- •Какие лимиты нужны: на пользователя, адрес, токен или на систему целиком?
- •Что важнее: абсолютная точность или простота и скорость работы?
- •Нужна ли распределённая консистентность счётчиков?
Архитектурный фокус
- •Выбор между накоплением токенов и скользящим окном в зависимости от сценария.
- •Распределённые счётчики со временем жизни и защитой от гонок.
- •Интеграция в шлюз API и понятные эксплуатационные метрики.
Типичные риски
- •Дрейф часов и гонки создают ложные ограничения.
- •Глобальные лимиты упираются в одно горячее хранилище.
Система уведомлений
Notification System
Практический кейс про многоканальную доставку, повторные попытки и обработку ошибочных сообщений.
Фокус: Многоканальная доставка уведомлений в больших объёмах.
Система должна совмещать скорость доставки, надёжность, управление стоимостью каналов и предпочтения пользователя.
Что уточнить на интервью
- •Какие каналы обязательны на старте?
- •Какие цели по задержке и успешной доставке важны для каждого канала?
- •Нужны ли шаблоны, локализация и настройки предпочтений пользователя?
Архитектурный фокус
- •Отдельные очереди и обработчики для каждого канала доставки.
- •Повторные попытки, очередь ошибочных сообщений и подавление дублей.
- •Отслеживание статуса доставки и аналитика по каналам.
Типичные риски
- •Дублирующиеся отправки при повторных попытках.
- •Проблемы у внешнего провайдера без резервного маршрута.
Платформа видеостриминга
Video Hosting
Кейс из темы 3 про путь загрузки, транскодирование и раздачу видео по миру.
Фокус: Загрузка, транскодирование и доставка видео.
Платформа должна провести видео через весь путь: от загрузки и подготовки файлов до стабильного воспроизведения в разных регионах.
Что уточнить на интервью
- •Какие форматы, разрешения и типы устройств обязательны на старте?
- •Какой профиль трафика ожидается: прямые эфиры или каталог роликов?
- •Нужны ли защита контента, географические ограничения и переключение качества по каналу?
Архитектурный фокус
- •Приём файлов, конвейер транскодирования и объектное хранилище.
- •Раздача через глобальную сеть доставки контента и региональные кэши.
- •Отдельный слой метаданных и интеграция с лентой или рекомендациями.
Типичные риски
- •Конвейер транскодирования становится узким местом.
- •Стоимость исходящего трафика и хранения быстро растёт.
Сервис геопоиска ближайших объектов
Google Maps Proximity
Практический кейс геопоиска: геопространственный индекс, ранжирование и горячие регионы.
Фокус: Поиск ближайших объектов по координатам пользователя.
Сервис должен быстро отвечать на запросы по ближайшим объектам и не терять качество выдачи при частых обновлениях координат.
Что уточнить на интервью
- •Какой радиус поиска и точность геоданных нужна?
- •Нужны ли дополнительные фильтры и ранжирование по расстоянию и релевантности?
- •Как часто обновляются координаты объектов?
Архитектурный фокус
- •Геопространственный индекс для разбиения карты и поиска соседних ячеек.
- •Отдельное хранилище для чтения и кэширование самых активных регионов.
- •Сервис ранжирования результатов по расстоянию и смысловой близости.
Типичные риски
- •Крупные города создают сильный перекос нагрузки.
- •Ошибки геоиндексации ухудшают качество выдачи.
Сервис райдшеринга
Uber
Кейс из темы 3 про геоподбор, жизненный цикл поездки и масштабирование в реальном времени.
Фокус: Подбор водителей и пассажиров в реальном времени.
Система должна быстро находить подходящего водителя, поддерживать отслеживание поездки и корректно пересчитывать время подачи.
Что уточнить на интервью
- •Как быстро должен происходить подбор и обновление времени подачи?
- •Как учитывать дорожную ситуацию и динамическое изменение цены?
- •Нужны ли сложные состояния поездки и отдельная обработка инцидентов?
Архитектурный фокус
- •Приём координат водителей и отдельный сервис геоподбора.
- •Явная модель состояний поездки и событийная координация шагов.
- •Сервис ценообразования и интеграция с расчётом маршрута.
Типичные риски
- •Шумные координаты ломают подбор ближайшего водителя.
- •Акции и динамическое ценообразование конфликтуют в биллинге.
Система продажи билетов
Система умной парковки
Кейс из темы 3 про конкуренцию за ограниченный инвентарь и атомарное бронирование.
Фокус: Продажа ограниченного инвентаря под высокой конкуренцией пользователей.
Пиковые распродажи создают экстремальную конкуренцию за ограниченный инвентарь и требуют безошибочной работы бронирования.
Что уточнить на интервью
- •Сколько времени место можно удерживать до оплаты?
- •Какие механизмы защиты от ботов обязательны?
- •Нужна ли виртуальная очередь в моменты пикового спроса?
Архитектурный фокус
- •Сервис бронирования с жёстким контролем доступного инвентаря.
- •Очередь ожидания для сглаживания наплыва пользователей.
- •Интеграция с оплатой и идемпотентный сценарий подтверждения брони.
Типичные риски
- •Овербукинг из-за гонок при бронировании.
- •Трафик ботов выбивает обычных пользователей из потока.
Система бронирования отелей
Hotel Booking
Практический кейс про модель доступности, сценарий бронирования и конкурентный доступ к инвентарю.
Фокус: Инвентарь номеров, календарь доступности и подтверждение брони.
Сервис должен совмещать поиск, цены, календари доступности, удержание номеров и последующее подтверждение брони.
Что уточнить на интервью
- •Как строятся правила отмены/изменения брони?
- •Как строго нужно удерживать номер на время оплаты?
- •Нужна ли интеграция с внешними каналами продаж и управления инвентарём?
Архитектурный фокус
- •Календарь доступности и отдельный сервис управления инвентарём.
- •Поисковый индекс, который получает обновления из транзакционного контура.
- •Сценарий бронирования, оплаты и подтверждения через события.
Типичные риски
- •Овербукинг при параллельных запросах.
- •Расхождение доступности между каналами продаж.
Распределённая файловая система
Distributed File System
Кейс из темы 3 про разделение метаданных и данных, репликацию и восстановление после отказов.
Фокус: Распределённое хранение файлов с репликацией и восстановлением после сбоев.
Система должна надёжно хранить большие файлы и при этом сохранять высокую скорость чтения и записи.
Что уточнить на интервью
- •Какие требования к долговечности и доступности действительно обязательны?
- •Какие размеры блоков и коэффициент репликации разумны для этой нагрузки?
- •Нужны ли строгие гарантии для чтения и записи?
Архитектурный фокус
- •Разделение узла метаданных и узлов данных с продуманным размещением блоков.
- •Репликация и повторное распределение блоков после отказов.
- •Оптимизация путей чтения и записи и проверка контрольных сумм.
Типичные риски
- •Слой метаданных становится единственной точкой отказа.
- •Восстановление после массового сбоя занимает слишком долго.
Распределённое хранилище типа «ключ-значение»
Key-Value Database
Кейс из темы 3 про партиционирование, репликацию, кворум и фоновое согласование данных.
Фокус: Базовое распределённое хранилище для чтения и записи под высокой нагрузкой.
Такое хранилище часто становится фундаментом для других сервисов, поэтому должно масштабироваться без потери предсказуемости.
Что уточнить на интервью
- •Какая модель консистентности нужна для чтения и записи?
- •Какой профиль нагрузки и какие размеры значений характерны для продукта?
- •Нужны ли время жизни записей, резервное копирование и работа в нескольких регионах?
Архитектурный фокус
- •Партиционирование, репликация и операции на основе кворума.
- •Выбор движка хранения и стратегия компакции.
- •Обнаружение отказов и фоновое согласование копий.
Типичные риски
- •Горячие партиции из-за неудачного выбора ключей.
- •Избыточная запись и скачки задержки во время компакции.
Межпланетная распределённая вычислительная система
Interplanetary Distributed Computing
Кейс из темы 3 про сети с большими задержками, автономные узлы и пакетную синхронизацию.
Фокус: Архитектура при огромных задержках и редких окнах связи.
Необычный сценарий для тренировки архитектурного мышления: сеть с задержками в минуты и часовые окна синхронизации.
Что уточнить на интервью
- •Какие задержки и окна связи возможны между узлами на Земле, орбите и других планетах?
- •Какие данные обязательно должны сходиться после восстановления связи?
- •Как проектировать деградацию при полном разрыве связи?
Архитектурный фокус
- •Передача данных с промежуточным сохранением и явный расчёт на большие задержки сети.
- •Согласование данных после восстановления связи с разрешением конфликтов на уровне домена.
- •Локальная автономность узлов и пакетная синхронизация.
Типичные риски
- •Синхронные протоколы ломаются из-за огромных задержек.
- •Конфликты данных копятся во время долгой автономной работы.
Рейтинг игроков в реальном времени
Real-time Gaming
Кейс из темы 3 про таблицу лидеров, быстрые обновления и выдачу ранга игрока.
Фокус: Быстрое обновление рейтинга игроков и выдача актуального положения в таблице.
Таблица лидеров должна быстро обновляться, корректно ранжировать миллионы игроков и поддерживать глобальные и региональные представления.
Что уточнить на интервью
- •Нужен один глобальный рейтинг или отдельные таблицы по регионам и сезонам?
- •Какая допустимая задержка обновления ранга?
- •Нужно ли учитывать сигналы защиты от мошенничества в конвейере подсчёта очков?
Архитектурный фокус
- •Быстрое хранилище рейтинга в памяти и периодическая фиксация состояния.
- •Событийное обновление очков и фоновая сверка результатов.
- •API для верхушки рейтинга и позиции игрока рядом с собой.
Типичные риски
- •Неравномерные записи на популярных игроков.
- •Расхождение между быстрым и долговременным представлением рейтинга.
Особенно интересная задача
Interplanetary Distributed Computing System особенно полезна как тренировка архитектурного мышления за пределами привычного дата-центра: здесь нужно проектировать систему для огромных задержек, редкой связи и длительной автономной работы узлов.
Связанная глава
System Design Primer (краткий обзор)
Шпаргалки по базовым паттернам, оценкам и кейсам для ежедневной практики.
Выводы и рекомендации
Кому подойдёт эта книга?
Тем, кто только собирает базу — книга хорошо раскладывает фундаментальные темы и даёт понятный ритм, по которому можно тренировать ответ.
Опытным инженерам — нестандартные задачи вроде межпланетной системы или игрового рейтинга помогают посмотреть на знакомые паттерны под другим углом.
Как дополнение к другим источникам — книга хорошо сочетается с более обзорными материалами и помогает довести структуру ответа до автоматизма.
Я бы использовал эту книгу как рабочий тренажёр: сначала пройти по ней базовый ритм ответа, затем сравнить его с более классическим разбором Alex Xu и закрепить всё регулярной практикой через system-design-primer.
Связанные главы
- Зачем читать книги для подготовки к интервью по системному дизайну - Контекст раздела и место книги Stanley Chiang в общей траектории подготовки.
- System Design Interview: An Insider's Guide (краткий обзор) - Классический разбор типовых кейсов, с которым удобно сравнить семишаговый ритм ответа из Hacking SDI.
- Acing the System Design Interview (краткий обзор) - Книга-компаньон с более методичным разбором ограничений, рисков и инженерных компромиссов.
- System Design Primer (краткий обзор) - Бесплатная база для повторения фундаментальных тем между прогоном интервью-кейсов.
- Interplanetary Distributed Computing System - Один из самых нестандартных кейсов книги: огромные задержки, автономная работа узлов и редкие окна синхронизации.
- Система умной парковки - Практический кейс про конкурентное бронирование мест, строгую консистентность и защиту от двойного бронирования.
- Система бронирования отелей - Кейс про календарь доступности, корректность цен и надёжность поиска и бронирования.
- Real-time Gaming - Практический кейс с жёсткими требованиями к задержке, синхронизации состояния и устойчивости сетевого канала.