Книга Zhiyong Tan ценна не тем, что предлагает еще один универсальный шаблон ответа, а тем, что учит разбирать задачу как инженерную ситуацию с контекстом, уточняющими вопросами и осознанным выбором глубины. Эта глава как раз показывает эту более методичную сторону материала.
В реальной инженерной практике она полезна тем, что помогает раскладывать систему на рабочие слои: интерфейсы, данные, асинхронные потоки, отказные сценарии, безопасность и эксплуатацию, а затем выбирать, какие узлы действительно стоит раскрывать подробнее.
Для подготовки к интервью эта глава особенно важна тем, что показывает, как превращать общий эскиз решения в последовательный инженерный разбор: сначала ограничения, затем архитектурный каркас, потом критичные детали и только после этого компромиссы и дальнейшую эволюцию.
Практическая польза главы
Декомпозиция задачи
Помогает разбивать задачу на проверяемые слои: API, данные, асинхронные потоки и отказные сценарии.
Контроль глубины
Учит выбирать, какие части углублять в зависимости от сигнала интервьюера и тайминга.
Риски и отказные сценарии
Делает явными точки отказа и операционные риски ещё до финализации архитектуры.
Коммуникация решения
Улучшает ясность ответа: ограничения, выбор архитектуры и план дальнейшей эволюции.
Разбор книги
Review: Acing the System Design Interview
Подробный разбор книги от Alexander Polomodov в блоге Code of Architecture
Acing the System Design Interview (System Design: пережить интервью)
Авторы: Zhiyong Tan
Издательство: Manning Publications
Объём: 472 страниц
Разбор книги Zhiyong Tan: структура ответа на интервью, методология проектирования, практические кейсы и общие сервисы.
Книга "Acing the System Design Interview" от Zhiyong Tan полезна тем, что учит проходить не как набор заученных паттернов, а как последовательный инженерный разбор задачи. Автор показывает, как двигаться от уточняющих вопросов и ограничений к архитектурному каркасу, а затем к тем узлам, которые действительно стоит раскрывать глубже.
Ключевое отличие
В отличие от Alex Xu, который быстрее вводит в типовые кейсы, Zhiyong Tan делает ставку на процесс проектирования и ритм разговора на интервью. Первые шесть глав здесь работают как методологическая база, а не как каталог готовых решений.
Об авторе
Zhiyong Tan — инженерный менеджер в PayPal. До этого он работал в Uber, стартапах и Teradata, совмещая опыт продуктовой разработки, платформенной инженерии и работы с данными.
Такой набор ролей чувствуется в книге: автор смотрит на проектирование систем и на подготовку к собеседованиям глазами человека, которому важно не только нарисовать схему, но и объяснить, как она будет жить в продакшене и как её защитить в разговоре с интервьюером.
Структура книги
1Часть 1: методологическая база (6 глав)
Структурированное введение в процесс проектирования: от базовых понятий и требований до распределённых транзакций и общих сервисов. Это методологическое ядро книги, которое задаёт формат ответа на интервью.
2Часть 2: практические кейсы (11 задач)
Набор типовых и менее очевидных задач, на которых можно тренировать структуру ответа, выбор глубины и обсуждение рисков.
3Приложения
Дополнительные материалы, к которым полезно возвращаться перед интервью:
Разбор первой части
Первые шесть глав формируют методологическую основу книги. Именно здесь автор связывает требования, , и в один разговор о том, как вести архитектурное интервью без спешки и хаоса.
1. Обзор ключевых концепций системного дизайна
В первой главе автор вводит базовые понятия системного дизайна и объясняет главную мысль книги: сильный ответ строится вокруг инженерных компромиссов, а не вокруг красивой схемы ради самой схемы.
Рассматриваемые темы:
2. Типичный ход интервью по системному дизайну
Вторая глава показывает базовый ритм интервью: сначала прояснить задачу, затем зафиксировать границы решения и только после этого переходить к архитектуре.
Функциональные требования
Что система должна делать: ключевые сценарии, роли пользователей и критичные действия
Нефункциональные требования
Как система должна работать: задержка, масштабируемость, надёжность и ограничения
Отдельно автор подчёркивает роль API-контракта, модели данных и верхнеуровневой архитектуры как трёх опорных точек хорошего ответа.
3. Нефункциональные требования
Третья глава подробно разбирает нефункциональные требования и помогает не сводить их к формальной мантре про "99.99%". Речь идёт о том, какие свойства системы действительно определяют архитектуру.
Масштабируемость
Способность расти вместе с нагрузкой
Доступность
Сколько времени система остаётся доступной
Надёжность
Насколько корректно система выполняет обещания
Сопровождаемость
Насколько легко её менять и поддерживать
Производительность
Задержка ответа и пропускная способность
Безопасность
Защита данных и управляющих контуров
4. Масштабирование баз данных
Четвёртая глава посвящена масштабированию баз данных — одной из ключевых тем любого интервью. Здесь появляются и как базовые способы расти по чтению и записи, а не как магические слова для любого случая.
Ключевые техники:
Репликация
Варианты синхронного и асинхронного копирования данных
Шардирование
Горизонтальное разделение данных по ключу
Агрегация событий
Выделение потока событий для аналитики и витрин
Стратегии кэширования
Основные модели чтения и записи через кэш
5. Распределённые транзакции
Пятая глава — одна из самых сильных в книге. Она объясняет, как работать с распределёнными операциями там, где один локальный коммит уже не решает задачу. Здесь появляются и как практические инструменты, а не как абстрактные определения.
Рассматриваемые паттерны:
Событийная архитектура
Асинхронное взаимодействие через события
Change Data Capture (CDC)
Вынос изменений из базы в поток событий
Паттерн Saga
Координация шагов через компенсирующие действия
Координатор распределённой операции
Явное управление состояниями и завершением шага
6. Общие сервисы
Шестая глава разбирает общие сервисы, которые всплывают почти в каждом кейсе. Здесь особенно полезно, что автор связывает доступ, защиту и эксплуатацию в одну рамку: , , , , , , и .
Аутентификация
JWT-токены, сессии, OAuth и OpenID Connect
Обработка ошибок
Повторы, тайм-ауты и размыкатель цепи
Ограничение запросов
Token Bucket, Leaky Bucket и защита от всплесков
Сервисная сетка
Istio, Linkerd и sidecar-подход
API-протоколы
REST, RPC и GraphQL
Логи и мониторинг
Наблюдаемость и разбор инцидентов
Часть 2: практические кейсы
Во второй части книги 11 практических кейсов. Ниже они идут в том же порядке, что и у автора, но с фокусом на том, что именно полезно вытащить для интервью.
Именно здесь книга начинает связывать отдельные домены в единую инженерную картину: подходы на основе , гарантии , , , , и .
Для потоковых и эксплуатационных сценариев особенно полезны разговоры про , , , , и .
Сокращатель ссылок
URL Shortener
API, стратегия коротких идентификаторов, редиректы, защита от злоупотреблений и масштабирование.
Фокус: Короткие ссылки, быстрые редиректы и защита от коллизий.
Продуктовый сценарий: пользователи и маркетинговые системы создают короткие ссылки, а основная нагрузка приходится на быстрые редиректы.
Что уточнить на интервью
- •Каково соотношение чтений и записей и какое соглашение по времени ответа на редирект?
- •Нужны ли кастомные алиасы, время жизни ссылки и удаление?
- •Нужна ли почти мгновенная статистика кликов?
Архитектурный фокус
- •Стратегия генерации идентификаторов и обработка коллизий.
- •Кэширование популярных ссылок и ускорение выдачи на краю сети.
- •Защита от злоупотреблений: ограничение частоты запросов, чёрные списки и валидация URL.
Типичные риски
- •Перебор коротких идентификаторов.
- •Горячие ключи из-за вирусных ссылок.
Хранилище типа «ключ-значение»
Key-Value Database
Шардирование, репликация, кворум и восстановление после отказов.
Фокус: Базовый движок хранения для чтения и записи под высокой нагрузкой.
Продуктовый сценарий: внутренний платформенный сервис хранения простых структур данных для других команд.
Что уточнить на интервью
- •Какая модель консистентности нужна для чтения?
- •Какие размеры значений и ограничения по ключам нужно поддержать?
- •Нужны ли работа в нескольких регионах, резервное копирование и время жизни записей?
Архитектурный фокус
- •Репликация и кворумные чтения/записи для баланса между задержкой и корректностью.
- •Шардирование и перебалансировка без длинных окон недоступности.
- •Выбор между LSM и B-tree, компакция и работа с усилением записи.
Типичные риски
- •Горячие партиции при неудачном выборе ключа.
- •Долгое восстановление и повторная синхронизация после сбоев.
Распределённая очередь сообщений
Distributed Message Queue
Партиционированный журнал, семантика доставки, повторные попытки и управление отставанием.
Фокус: Надежная асинхронная шина для сервисов и фоновых задач.
Продуктовый сценарий: развязка между сервисами, обработка всплесков нагрузки и гарантии доставки для критичных событий.
Что уточнить на интервью
- •Нужна ли доставка не более одного раза, как минимум один раз или идемпотентная обработка повторов?
- •Важен ли строгий порядок глобально или только внутри партиции?
- •Какие требования к задержке и сроку хранения сообщений?
Архитектурный фокус
- •Партиционирование и группы потребителей для горизонтального масштабирования.
- •Повторные попытки, очередь ошибочных сообщений и идемпотентные обработчики.
- •Обратное давление и управление потоком при всплесках нагрузки.
Типичные риски
- •Проблемные сообщения, которые ломают обработчик.
- •Неконтролируемое отставание при медленных потребителях.
Социальная сеть
Twitter/X
Социальная лента: стратегии раздачи, кэши и работа под высокой нагрузкой.
Фокус: Лента и социальные взаимодействия для массового B2C-продукта.
Продуктовый сценарий: публикация контента, подписки, персональная лента и реакция на вирусный рост трафика.
Что уточнить на интервью
- •Какие основные действия нужно поддержать: публикации, подписки, лайки, комментарии?
- •Какой таргет по DAU и задержке открытия ленты важен для продукта?
- •Нужна ли персонализация/ранжирование на первом этапе?
Архитектурный фокус
- •Стратегия раздачи ленты: запись в ленты заранее, чтение на лету или гибридный вариант.
- •Многоуровневый кэш для таймлайна, объектов и метаданных.
- •Асинхронные конвейеры для обработки медиа и счётчиков.
Типичные риски
- •Эффект знаменитости с резким всплеском раздачи.
- •Расхождения между кэшем ленты и основным источником данных.
Агрегатор событий рекламных кликов
Ad Click Event Aggregator
Потоковый конвейер для агрегатов, свежесть данных и точность биллинга.
Фокус: Конвейер аналитики кликов для отчётов и биллинга.
Продуктовый сценарий: агрегация рекламных событий почти в реальном времени с контролем качества данных.
Что уточнить на интервью
- •Какой горизонт обновления нужен: потоковая витрина или почасовой пакетный расчёт?
- •Какая точность нужна для биллинга?
- •Как обрабатывать события, пришедшие не по порядку и с опозданием?
Архитектурный фокус
- •Приём событий и удаление дублей по ключу идемпотентности.
- •Оконные агрегации и стратегия работы с водяными знаками.
- •Совместимость потокового расчёта с историческим пересчётом.
Типичные риски
- •Двойной учёт из-за повторной доставки.
- •Расхождения между онлайн- и офлайн-расчётами.
Объектное хранилище
Object Storage
Архитектура объектного хранилища, разделение метаданных и данных и механизмы долговечности.
Фокус: Хранилище больших объектов для медиа, бэкапов и артефактов.
Продуктовый сценарий: недорогое и долговечное хранилище с простым API и политиками жизненного цикла.
Что уточнить на интервью
- •Какой уровень долговечности и доступности нужен, например в районе одиннадцати девяток?
- •Какие типовые размеры объектов и профиль чтений/записей?
- •Нужны ли версионирование, политики жизненного цикла и уровни хранения?
Архитектурный фокус
- •Разделение метаданных и данных с независимым масштабированием слоёв.
- •Кодирование с избыточностью или репликация и фоновое восстановление.
- •Многокомпонентная загрузка, проверка контрольных сумм и подписанные URL.
Типичные риски
- •Узкое место в слое метаданных при росте пространства имён.
- •Высокая цена межрегиональной репликации.
Платёжное приложение
Payment System
Идемпотентность, сценарии списания и возврата, оркестрация платежей и сверка.
Фокус: Платежный контур с сильными гарантиями корректности.
Продуктовый сценарий: движение денег, где цена ошибки выше цены лишней задержки и нужен строгий аудит.
Что уточнить на интервью
- •Какие платёжные сценарии нужны: авторизация, списание, возврат, чарджбэк?
- •Какие требования по соответствию правилам и аудиту?
- •Как обрабатываются дублирующиеся запросы и частичные сбои?
Архитектурный фокус
- •Ключи идемпотентности и конечный автомат транзакций.
- •Двухпроводочный журнал операций как основной источник истины.
- •Сверка с внешними платёжными провайдерами и компенсирующие действия.
Типичные риски
- •Повторные списания из-за повторных попыток.
- •Расхождения между внутренним журналом операций и платёжным провайдером.
Инфраструктурный взгляд на социальную сеть
Social Media Infrastructure View
Платформенный контур социальной системы: деградация, изоляция отказов и наблюдаемость.
Фокус: Тот же домен, но с акцентом на платформенный контур и эксплуатацию.
Продуктовый сценарий: переход от функциональной схемы к эксплуатационной архитектуре и управлению через целевой уровень сервиса.
Что уточнить на интервью
- •Какие целевые уровни сервиса и бюджет ошибок нужны для ключевых пользовательских сценариев?
- •Где нужны автоскейлинг и плавная деградация?
- •Какими должны быть границы радиуса поражения между сервисами?
Архитектурный фокус
- •Границы сервисов, контракт API и версионирование.
- •Базовый контур наблюдаемости: логи, метрики, трассировки и маршрутизация алертов.
- •Топология развёртывания по нескольким зонам доступности, стратегия выката и откат.
Типичные риски
- •Каскадные сбои без изоляции и защитных ограничителей.
- •Непрозрачные инциденты без сквозной трассировки.
Сервис бронирования жилья и маркетплейс
Airbnb
Двусторонний маркетплейс, поиск, календарь доступности и конкуренция за слоты.
Фокус: Маркетплейс бронирований с высокой конкуренцией за один и тот же слот.
Продуктовый сценарий: поиск вариантов и атомарное бронирование ресурсов в условиях гонки за один и тот же слот.
Что уточнить на интервью
- •Какие правила временной брони, подтверждения и отмены нужно поддержать?
- •Сколько параллельных попыток на один слот ожидается?
- •Как формируется поисковая выдача: фильтры, сортировка, география?
Архитектурный фокус
- •Модель инвентаря и выбор между оптимистической и пессимистической блокировкой.
- •Сценарий бронирования с тайм-аутом на временную бронь.
- •Поисковый индекс с согласованием со временем относительно транзакционного хранилища.
Типичные риски
- •Овербукинг при гонках за один слот.
- •Плохой пользовательский опыт из-за долгих подтверждений.
Контроль доступа и авторизация в медиа-приложении
Access Control for Media App
Модели доступа, разделение принятия и применения политики, журнал аудита и безопасная инвалидация кэша.
Фокус: Контур авторизации для медиаплатформы с разными ролями и правилами доступа.
Продуктовый сценарий: единая модель политик для веб-клиента, мобильного приложения и административного интерфейса с принципом минимально необходимых прав.
Что уточнить на интервью
- •Какие роли и ресурсы критичны на старте?
- •Достаточно ли одной ролевой модели доступа или нужен гибрид нескольких подходов?
- •Нужны ли отдельные API для объяснения решений и расследований?
Архитектурный фокус
- •Разделение точки принятия решения и точки применения политики доступа.
- •Кэширование решений с корректной инвалидацией.
- •Изоляция арендаторов и неизменяемый журнал аудита.
Типичные риски
- •Эскалация привилегий из-за неявных правил.
- •Устаревший кэш правил после обновления прав.
Панель топ-продуктов
Top Products Dashboard
Аналитическая витрина: предварительные агрегации, согласованность метрик и свежесть данных.
Фокус: BI-дэшборд топ-продуктов для операционных и продуктовых команд.
Продуктовый сценарий: аналитический интерфейс, где важны объяснимость метрик и понятная свежесть данных.
Что уточнить на интервью
- •Какая целевая частота обновления и допустимая задержка?
- •Какие измерения и фильтры нужны бизнесу?
- •Нужна ли детализация вплоть до сырых событий?
Архитектурный фокус
- •Отдельный слой выдачи под нагрузки аналитической витрины.
- •Предварительные агрегации и материализованные представления для приемлемой задержки.
- •Комбинация потокового обновления и планового исторического пересчёта.
Типичные риски
- •Тяжёлые произвольные запросы перегружают рабочую OLTP-систему.
- •Непонимание свежести данных и расхождение цифр между витринами.
Выводы и рекомендации
Кому подойдёт эта книга?
Тем, кто хочет понимать логику ответа — книга даёт методологическую основу, а не просто набор готовых схем.
Инженерам с опытом — глубокий разбор распределённых транзакций и общих сервисов особенно полезен тем, кто уже устал от слишком поверхностных обзоров.
Для долгосрочной подготовки — книга формирует устойчивое понимание архитектурных решений, а не поверхностное знание отдельных паттернов.
Рекомендация: Используйте эту книгу как основной источник для понимания процесса и ритма ответа, а книгу Alex Xu держите рядом как более быстрый справочник по типовым системам.
Связанные главы
- Зачем читать книги для подготовки к интервью по системному дизайну - Карта раздела и место книги Zhiyong Tan в общей траектории подготовки.
- System Design Interview: An Insider's Guide (краткий обзор) - Книга-компаньон с более быстрым входом в типовые кейсы и понятным базовым каркасом ответа.
- Hacking the System Design Interview (краткий обзор) - Альтернативный семишаговый подход и дополнительный набор задач для отработки формата интервью.
- System Design Primer (краткий обзор) - Базовый репозиторий для повторения ключевых паттернов и регулярной тренировки.
- Distributed Message Queue - Кейс из книги про партиционирование, гарантии доставки и контроль отставания потребителей.
- Top Products Dashboard - Аналитический кейс из книги про свежесть данных, аналитическую витрину и сверку показателей.
- Social Media Infrastructure View - Платформенный взгляд на социальную систему: плавная деградация, изоляция отказов и работа по целевому уровню сервиса.
- Access Control for Media App - Практика проектирования контура авторизации, политик доступа и журнала аудита под нагрузкой.