Книга Stanley Chiang сильна не тем, что обещает “взломать” interview магическим приемом, а тем, что собирает подготовку в очень практичный маршрут: базовые концепции, типовые компоненты, 7-шаговый подход и большой набор задач. Эта глава как раз показывает, почему материал ощущается более прикладным и систематизированным.
В реальной инженерной практике она полезна тем, что дисциплинирует движение по задаче под давлением времени: сначала понять границы системы, затем собрать модель данных и оценки нагрузки, после этого выбрать архитектуру и только потом уходить в узкие места и компромиссы.
Для подготовки к интервью эта глава особенно ценна тем, что переводит теорию в режим повторяемой тренировки: 7 шагов дают устойчивый ритм ответа, а 16 практических кейсов позволяют проверять, где разваливается структура, где не хватает базы и какие deep dives еще не держатся уверенно.
Практическая польза главы
Каркас интервью
Дает дисциплину прохождения кейса под давлением времени и переключений контекста.
Сравнение альтернатив
Учит держать 2-3 варианта на критичные узлы и аргументированно выбирать один.
Операционный минимум
Подсвечивает необходимость observability, degradation-стратегий и rollback сценариев.
Репетиция формата
Помогает перевести теорию в повторяемый mock-режим с измеримым прогрессом.
Источник
Оригинальная статья
Обзор книги Hacking the System Design Interview в блоге Code of Architecture
Hacking the System Design Interview
Авторы: Stanley Chiang
Издательство: Independently published, 2022
Объём: —
Разбор книги Stanley Chiang: 7-шаговый фреймворк, 16 практических задач и сравнение с другими материалами.
Личное мнение
Эта книга показалась мне интереснее, чем "System Design Interview" от Alex Xu. Структура изложения базовых концепций здесь более понятная и систематизированная.
Связанная глава
Зачем читать книги по System Design Interview
Карта источников: как комбинировать книги, курсы и практические кейсы в единый план подготовки.
Структура книги
Книга состоит из введения, в котором автор рассказывает общие слова про system design interview, а также трёх основных частей:
1. The System Design Interview
Краткое интро про этот тип интервью и про то, как использовать книгу для подготовки к нему.
2. Essential Concepts
Базовая терминология и фундаментальные принципы для дизайна сервисов:
3. Core Components
Базовые компоненты современных систем:
4. System Design Questions
Семишаговый подход к решению задач, методы приблизительной оценки, рисование диаграмм и 16 практических задач для отработки навыков.
Связанная глава
Фреймворки прохождения интервью
Дополнительные структуры ответа на System Design Interview и практики тайм-менеджмента.
7-шаговый подход к System Design
Фреймворк, который предлагает автор, состоит из семи последовательных шагов. Давайте разберём каждый из них подробно.
Понимание задачи и определение границ
На этом этапе нужно выяснить у интервьюера какие функции должна поддерживать система. Это позволит избежать ненужных углублений и определиться, насколько глубоко нужно нырнуть в каждую из тем.
Ключевые вопросы:
- Какие основные use cases должна поддерживать система?
- Каковы ожидаемые нагрузки (пользователи, запросы в секунду)?
- Какие есть ограничения по времени/бюджету?
Определение модели данных
На втором этапе нужно определиться какими сообщениями обмениваются элементы системы и какие данные хранятся в системе.
Сообщения (Messages)
Форматы обмена данными между компонентами системы
Хранилище (Storage)
Схема данных и выбор типа хранилища
Высокоуровневая оценка нагрузки
Проводим Back of the Envelope Estimation — прикидываем порядки величин для основных метрик системы.
Что оцениваем:
- Количество пользователей (DAU/MAU)
- Количество запросов в секунду (QPS)
- Объём хранимых данных
- Пропускная способность сети
Высокоуровневый дизайн
После определения основных требований и характеристик строим высокоуровневую архитектуру и согласовываем её с интервьюером. Это критически важный момент!
Обязательно получите подтверждение от интервьюера, что вы на правильном пути, прежде чем углубляться в детали.
Детальный дизайн
После согласования высокоуровневого дизайна переходим к детальному проектированию критически важных частей системы.
На что обратить внимание:
- Детали реализации ключевых компонентов
- Алгоритмы и структуры данных
- Обработка edge cases
- Выбор конкретных технологий
Спецификация API и интерфейсов
Определяем публичные API системы и интерфейсы взаимодействия между компонентами.
Внешние API
REST, GraphQL, gRPC эндпоинты для клиентов
Внутренние интерфейсы
Контракты между микросервисами
Обсуждение узких мест и производительности
Финальный этап — обсуждение потенциальных проблем и способов их решения.
Темы для обсуждения:
- Bottlenecks и способы их устранения
- Single points of failure
- Масштабирование под рост нагрузки
- Мониторинг и alerting
16 практических задач
Ниже полный список задач в формате interview-playbook: для каждой задачи выделены фокус, вопросы на уточнение, архитектурные решения и типичные риски.
Design URL Shortener
URL Shortener
Практический кейс: short ID strategy, redirect path и anti-abuse.
Фокус: Короткие ссылки, быстрые редиректы и борьба с коллизиями.
Сервис должен стабильно обрабатывать большой read-heavy трафик и сохранять предсказуемую latency на редирект.
Что уточнить на интервью
- •Какой read/write ratio и целевой p95 latency на redirect?
- •Нужны ли кастомные alias, TTL, delete/disable ссылок?
- •Есть ли требования к аналитике кликов в near-realtime?
Архитектурный фокус
- •ID generation strategy + контроль коллизий.
- •Кэш hot links и CDN/edge для ускорения redirects.
- •Anti-abuse слой: rate limiting, валидация URL, blacklist.
Типичные риски
- •Enumeration атакуют предсказуемые short ID.
- •Hot keys на вирусных ссылках.
Design Chat System
Chat System
Практический кейс: transport, delivery semantics и presence.
Фокус: Realtime обмен сообщениями, presence и доставка в офлайне.
Чат должен поддерживать p2p и групповые диалоги при стабильной доставке сообщений и синхронизации между устройствами.
Что уточнить на интервью
- •Нужны ли message ordering guarantees в чатах?
- •Какие требования к online presence и typing indicators?
- •Нужны ли read receipts, media attachments, message history sync?
Архитектурный фокус
- •WebSocket/gRPC streams для realtime канала.
- •Message queue + async delivery workers + push fallback.
- •Хранение истории и sync-процессы между devices.
Типичные риски
- •Stateful соединения усложняют масштабирование.
- •Потеря сообщений при failover без durable queue.
Design Search Autocomplete
Search System
Кейс из темы 3: indexing, retrieval и latency-бюджет поиска.
Фокус: Подсказки в поиске с минимальной задержкой.
Система должна выдавать релевантные подсказки на каждый символ ввода и выдерживать всплески поисковых запросов.
Что уточнить на интервью
- •Нужна ли персонализация подсказок или глобальный top-k?
- •Как часто обновляется модель частотности запросов?
- •Какой набор языков/локалей поддерживается?
Архитектурный фокус
- •Trie/DAWG структура + precomputed top-k по префиксам.
- •Поток обновлений запросов через batch/stream pipeline.
- •Кэширование hot prefixes на edge/прикладном уровне.
Типичные риски
- •Heavy write pipeline приводит к stale suggestions.
- •Неравномерные hot prefixes создают перегрузку.
Design News Feed
Twitter/X
Практический кейс social feed: fan-out и кэширование.
Фокус: Лента контента с fan-out стратегиями.
Фид должен корректно обновляться при высокой активности пользователей и поддерживать персонализацию/ранжирование.
Что уточнить на интервью
- •Какой SLA на открытие ленты и публикацию поста?
- •Нужна ли строгая хронология или ranking-first лента?
- •Какие лимиты по подпискам и активности у heavy users?
Архитектурный фокус
- •Fanout-on-write / fanout-on-read / hybrid strategy.
- •Timeline cache + object cache + counters pipeline.
- •Async processing для media и engagement signals.
Типичные риски
- •Celebrity fan-out перегружает write path.
- •Дрейф между source of truth и cached timeline.
Design Web Crawler
Web Crawler
Кейс из темы 3: frontier, deduplication и politeness.
Фокус: Масштабный обход web-графа с контролем качества.
Краулер должен устойчиво обрабатывать миллиарды URL, избегая дублей и сохраняя вежливое поведение к внешним доменам.
Что уточнить на интервью
- •Какой объём crawl/day и требуемая свежесть индекса?
- •Какие типы контента/файлов нужно извлекать?
- •Нужны ли ограничения robots.txt / rate limits per domain?
Архитектурный фокус
- •URL frontier с приоритезацией и politeness policy.
- •Fetcher workers + deduplication + canonicalization.
- •Pipeline парсинга, extraction и enqueue новых URL.
Типичные риски
- •Crawler traps и бесконечные графы ссылок.
- •Слишком агрессивный crawl приводит к blocking.
Design Rate Limiter
Rate Limiter
Кейс из темы 3: алгоритмы лимитирования и distributed counters.
Фокус: Контроль трафика и защита API от перегрузки.
Rate limiter должен работать как инфраструктурный компонент для разных сервисов и корректно выдерживать burst нагрузку.
Что уточнить на интервью
- •Какие лимиты: per-user, per-IP, per-token, global?
- •Какие алгоритмы важнее: точность или простота/скорость?
- •Нужна ли распределённая консистентность счётчиков?
Архитектурный фокус
- •Token Bucket/Sliding Window в зависимости от use case.
- •Distributed counters с TTL и защитой от race conditions.
- •Интеграция в API gateway и observability metrics.
Типичные риски
- •Clock drift и race дают ложные лимиты.
- •Single storage hotspot для глобальных лимитов.
Design Notification System
Notification System
Практический кейс: multi-channel delivery и retry/DLQ.
Фокус: Push/SMS/email уведомления в больших объёмах.
Многоканальная система должна балансировать скорость доставки, надёжность и ограничение стоимости каналов.
Что уточнить на интервью
- •Какие каналы обязательны на старте?
- •Какие SLO по задержке и доставке на каждый канал?
- •Нужны ли шаблоны, локализация, preference center?
Архитектурный фокус
- •Channel-specific queues и workers.
- •Retry policy + dead-letter queue + deduplication.
- •Delivery status tracking и аналитика каналов.
Типичные риски
- •Дубли отправок при retries.
- •Vendor outage без fallback-провайдера.
Design Video Streaming Platform
Video Hosting
Кейс из темы 3: upload pipeline, transcoding и CDN delivery.
Фокус: Загрузка, транскодирование и доставка видео.
Платформа должна обрабатывать media pipeline end-to-end: от upload до playback с разными битрейтами и регионами.
Что уточнить на интервью
- •Какие целевые форматы/разрешения и supported devices?
- •Какой expected traffic profile (live vs VOD)?
- •Нужны ли DRM, geo-restrictions и adaptive bitrate?
Архитектурный фокус
- •Ingestion + transcoding pipeline + object storage.
- •CDN distribution + caching strategy по регионам.
- •Metadata service + recommendation/feed integration.
Типичные риски
- •Transcoding pipeline становится bottleneck.
- •Высокая стоимость egress и storage tiering.
Design Proximity Service
Google Maps Proximity
Практический кейс геопоиска: spatial index и ranking.
Фокус: Поиск ближайших объектов по геолокации.
Сервис должен отвечать быстро на spatial queries и корректно работать с geospatial индексацией и обновлениями.
Что уточнить на интервью
- •Какой радиус поиска и точность геоданных нужна?
- •Нужны ли geo-filters и ranking по distance + relevance?
- •Как часто обновляются координаты объектов?
Архитектурный фокус
- •Geohash/S2/H3 индекс для spatial partitioning.
- •Read-optimized geo storage + cache hot regions.
- •Сервис ранжирования результатов по distance/relevance.
Типичные риски
- •Hot city regions создают перекос нагрузки.
- •Неправильная геоиндексация ухудшает качество выдачи.
Design Ride Sharing
Uber
Кейс из темы 3: geo-matching, trip workflow и scaling.
Фокус: Матчинг водителей и пассажиров в realtime.
Система должна в режиме near-realtime находить оптимального водителя и поддерживать live-трекинг поездки.
Что уточнить на интервью
- •Какие SLA на matching и обновление ETA?
- •Как учитывать surge pricing и traffic conditions?
- •Нужны ли multi-hop trip states и incident handling?
Архитектурный фокус
- •Driver location ingestion + geo-index matching service.
- •Trip state machine + event bus для workflow.
- •Pricing service + route optimization integration.
Типичные риски
- •Скачки GPS/telemetry ломают matching.
- •Surge/promo конфликтуют в биллинге.
Design Ticketing System
Ticket Booking
Кейс из темы 3: конкуренция за слоты и атомарное бронирование.
Фокус: Продажа билетов под высокой конкуренцией пользователей.
Пиковые распродажи создают экстремальную конкуренцию за ограниченный инвентарь и требуют строгой корректности броней.
Что уточнить на интервью
- •Какой hold timeout и подтверждение оплаты?
- •Какие anti-bot механики обязательны?
- •Нужен ли waiting room при пиковых продажах?
Архитектурный фокус
- •Reservation service с блокировкой inventory.
- •Queue/virtual waiting room для сглаживания наплыва.
- •Payment integration + idempotent booking flow.
Типичные риски
- •Overselling из-за race conditions.
- •Bot traffic выбивает легальных пользователей.
Design Hotel Reservation System
Hotel Booking
Практический кейс: availability model, booking flow и конкурентный доступ.
Фокус: Инвентарь номеров, availability и бронирование.
Сервис должен поддерживать поиск и подтверждение брони с учётом календарей доступности, тарифов и отмен.
Что уточнить на интервью
- •Как строятся правила отмены/изменения брони?
- •Какие требования к atomic booking и hold room?
- •Нужна ли интеграция с внешними channel managers?
Архитектурный фокус
- •Availability calendar + inventory management service.
- •Search index с eventual consistency от transactional store.
- •Booking workflow + payment + confirmation events.
Типичные риски
- •Overbooking при параллельных запросах.
- •Рассинхрон availability между каналами продаж.
Design Distributed File System
Distributed File System
Кейс из темы 3: metadata/data split, replication и recovery.
Фокус: Распределённое хранение файлов с репликацией.
Система должна обеспечивать надёжное хранение больших файлов и высокую пропускную способность чтения/записи.
Что уточнить на интервью
- •Какие требования к durability/availability?
- •Какие размеры блоков и replication factor оптимальны?
- •Нужны ли consistency guarantees на уровне read/write?
Архитектурный фокус
- •Metadata node + data nodes + block placement.
- •Replication strategy и re-replication после отказов.
- •Read/write path optimization и checksum verification.
Типичные риски
- •Metadata node становится SPOF/bottleneck.
- •Длительное восстановление после массового отказа.
Design Distributed Key-Value Store
Key-Value Database
Кейс из темы 3: partitioning, replication, quorum и anti-entropy.
Фокус: Low-latency распределённое KV-хранилище.
KV storage используется как фундаментальный building block для других сервисов и должен масштабироваться горизонтально.
Что уточнить на интервью
- •Какая модель консистентности нужна: strong/eventual/tunable?
- •Какой профиль нагрузок read/write и размеры values?
- •Нужны ли TTL, backup/restore, multi-region replication?
Архитектурный фокус
- •Partitioning + replication + quorum operations.
- •Storage engine decisions (LSM/B-tree) и compaction.
- •Failure detection и anti-entropy механизмы.
Типичные риски
- •Hot partitions из-за неудачных ключей.
- •Write amplification и latency spikes на compaction.
Design Interplanetary Distributed Computing System
Interplanetary Distributed Computing
Кейс из темы 3: delay-tolerant сеть, store-and-forward и автономные узлы.
Фокус: Архитектура при экстремальной latency и ограниченной связи.
Необычный сценарий для тренировки архитектурного мышления: сеть с задержками в минуты и редкими окнами синхронизации.
Что уточнить на интервью
- •Какой latency budget между узлами (земля/орбита/планеты)?
- •Какие данные критичны для eventual sync?
- •Как проектировать деградацию при полном разрыве связи?
Архитектурный фокус
- •Store-and-forward коммуникации и delay-tolerant networking.
- •Eventual consistency с конфликт-резолюцией на уровне домена.
- •Локальная автономность узлов и пакетная синхронизация.
Типичные риски
- •Долгие сети ломают синхронные протоколы.
- •Конфликты данных копятся при длительном offline.
Design Real-time Gaming Leaderboard
Real-time Gaming
Кейс из темы 3: leaderboard, realtime updates и ranking queries.
Фокус: Обновление рейтинга игроков в realtime.
Leaderboard должен быстро обновляться, корректно ранжировать миллионы игроков и поддерживать региональные/глобальные таблицы.
Что уточнить на интервью
- •Нужен глобальный leaderboard или per-region/per-season?
- •Какая допустимая задержка обновления ранга?
- •Нужны ли anti-cheat сигналы в scoring pipeline?
Архитектурный фокус
- •In-memory ranking store (sorted sets) + periodic persistence.
- •Event-driven score updates и batch reconciliation.
- •Read API для top-N и around-me запросов.
Типичные риски
- •Skewed writes на популярных игроков.
- •Несогласованность realtime и persisted rankings.
Особенно интересная задача
Interplanetary Distributed Computing System тренирует мышление для extreme-case сетей: очень большие задержки, редкая синхронизация и необходимость автономной работы узлов.
Связанная глава
System Design Primer (short summary)
Шпаргалки по базовым паттернам, оценкам и кейсам для ежедневной практики.
Выводы и рекомендации
Кому подойдёт эта книга?
Начинающим — хорошая структура базовых концепций поможет систематизировать знания.
Опытным инженерам — уникальные задачи вроде "Interplanetary System" дадут новый взгляд на знакомые концепции.
Как дополнение — книга отлично работает в связке с другими материалами по System Design.
Рекомендую использовать эту книгу как один из источников при подготовке, комбинируя её с "System Design Interview" от Alex Xu и репозиториемsystem-design-primer.
Связанные главы
- Зачем читать книги по System Design Interview - Контекст раздела и как книга Stanley Chiang дополняет остальные источники подготовки.
- System Design Interview: An Insider's Guide (short summary) - Классический interview walkthrough для сравнения с 7-шаговым подходом из Hacking SDI.
- Acing the System Design Interview (short summary) - Методологическая альтернатива с акцентом на архитектурные trade-offs и distributed patterns.
- System Design Primer (short summary) - Чеклистный open-source источник для регулярного повторения базовых концепций.
- Interplanetary Distributed Computing System - Один из самых нестандартных кейсов книги: extreme latency, offline-first и delay-tolerant дизайн.
- Система бронирования билетов - Практика high-contention сценариев: инвентарь, согласованность и защита от oversell.
- Система бронирования отелей - Кейс про availability calendar, pricing consistency и надёжность поиска/бронирования.
- Real-time Gaming - Realtime кейс из книги: низкая latency, state sync и устойчивость к packet loss/jitter.