System Design II, Распределенные системы, Подготовка к сложному интервью, Сюй А., Лэм С., 2026

System Design II, Распределенные системы, Подготовка к сложному интервью, Сюй А., Лэм С., 2026.

   «System Design. Распределенные системы. Подготовка к сложному интервью» — это практическое руководство для инженеров и архитекторов, которое поможет справиться с самыми трудными техническими заданиями. Алекс Сюй и Сан Лэм предлагают стратегию, проверенную на практике, пошаговые алгоритмы и реальные примеры, позволяющие научить вас проектировать масштабируемые системы — от новостной ленты до поисковых сервисов и чат-приложений. Книга сочетает теорию и практику, дает ясные объяснения и сотни диаграмм, превращая пугающие интервью в понятный процесс.
Пройти такое собеседование непросто, поскольку в проектировании ИТ-систем не существует единственно правильных решений. Речь идет о самых разнообразных реальных системах, обладающих множеством особенностей. Вам могут предложить выбрать общую архитектуру, а потом пройтись по всем компонентам или, наоборот, сосредоточиться на каком-то одном аспекте. Но в любом случае вы должны продемонстрировать понимание и знание системных требований, ограничений и узких мест.
Правильная стратегия и знания являются ключевыми факторами успешного прохождения интервью!




Эксплуатационные ограничения квадродерева.
Как уже говорилось выше, построение квадродерева с 200 миллионами организаций при запуске сервера может занять несколько минут. Важно учитывать эксплуатационные последствия такого длительного процесса. Пока дерево строится, сервер не может обслуживать трафик. Поэтому нужно добавить новый сервер в дополнение к уже имеющимся. Это позволит избежать отключений и перебоев в обслуживании. Можно также использовать сине-зеленое развертывание, но целый кластер серверов, одновременно получающих данные о 200 миллионах мест из базы, может сильно нагрузить систему. Это реализуемо, но существенно усложнит дизайн, и об этом нужно упомянуть на собеседовании.

Еще один важный вопрос — как обновлять дерево по мере добавления и удаления организаций. Самый простой подход — постепенно перестраивать квадродерево на небольшом подмножестве серверов за раз, не во всем кластере одновременно. Но это означает, что некоторые серверы в течение короткого периода времени будут возвращать устаревшие данные. В целом это приемлемый компромисс, если исходить из предъявляемых к системе требований. Можно дополнительно смягчить эту проблему, установив такое бизнес-правило: но-вые/обновленные организации появятся в поиске только на следующий день. Это означает, что можно обновлять кэш с помощью ночного задания. Одна из потенциальных проблем такого подхода заключается в том, что одновременно станут недействительными миллионы ключей, а это приведет к большой нагрузке на кэш-серверы.

ОГЛАВЛЕНИЕ.
От издательства.
О научном редакторе русского издания.
Предисловие.
Благодарности.
Глава 1. Организации рядом.
Шаг 1: понять задачу и определить масштаб решения.
Функциональные требования.
Нефункциональные требования.
Приблизительные оценки.
Шаг 2: предложить высокоуровневый дизайн и получить одобрение.
Дизайн API.
Модель данных.
Высокоуровневый дизайн.
Алгоритмы для поиска организаций рядом.
Шаг 3: детали дизайна.
Масштабирование базы данных.
Кэширование.
Регионы и зоны доступности.
Дополнительный вопрос: фильтр по времени работы или типу бизнеса.
Финальная схема дизайна.
Шаг 4: итоги.
Краткий обзор главы.
Ссылки.
Глава 2. Друзья поблизости.
Шаг 1: понять задачу и определить масштаб решения.
Функциональные требования.
Нефункциональные требования.
Приблизительные оценки.
Шаг 2: предложить высокоуровневый дизайн и получить одобрение.
Высокоуровневый дизайн.
Периодическое обновление местоположения.
Дизайн API.
Модель данных.
Шаг 3: детали дизайна.
Насколько хорошо масштабируется каждый компонент?.
Добавление/удаление друзей.
Пользователи с большим количеством друзей.
Незнакомец поблизости.
Альтернатива Redis Pub/Sub.
Шаг 4: итоги.
Краткий обзор главы.
Ссылки.
Глава 3. Google Карты.
Шаг 1: понять задачу и определить масштаб решения.
Функциональные требования.
Нефункциональные требования и ограничения.
Основы картографии.
Приблизительные оценки.
Шаг 2: предложить высокоуровневый дизайн и получить одобрение.
Высокоуровневый дизайн.
Шаг 3: детали дизайна.
Модель данных.
Сервисы.
Шаг 4: итоги.
Краткий обзор главы.
Ссылки.
Глава 4. Распределенная очередь сообщений.
Шаг 1: понять задачу и определить масштаб решения.
Функциональные требования.
Нефункциональные требования.
Настройки для традиционных очередей сообщений.
Шаг 2: предложить высокоуровневый дизайн и получить одобрение.
Модели обмена сообщениями.
Топики, партиции и брокеры.
Группа потребителей.
Высокоуровневый дизайн.
Шаг 3: детали дизайна.
Хранилище данных.
Структура данных сообщения.
Пакетная обработка.
Поток производителя.
Поток потребителя.
Перебалансировка потребителей.
Хранилище состояний.
Хранилище метаданных.
ZooKeeper.
Репликация.
Масштабируемость.
Семантики доставки данных.
Дополнительные возможности.
Шаг 4: итоги.
Краткий обзор главы.
Ссылки.
Глава 5. Система мониторинга и оповещений.
Шаг 1: понять задачу и определить масштаб решения.
Общие требования и допущения.
Нефункциональные требования.
Шаг 2: предложить высокоуровневый дизайн и получить одобрение.
Основы.
Модель данных.
Высокоуровневый дизайн.
Шаг 3: детали дизайна.
Сбор метрик.
Масштабирование конвейера передачи метрик.
Где может происходить агрегирование метрик.
Сервис запросов.
Слой хранения.
Система оповещения.
Система визуализации.
Шаг 4: итоги.
Краткий обзор главы.
Ссылки.
Глава 6. Агрегация рекламных кликов.
Шаг 1: понять задачу и определить масштаб решения.
Функциональные требования.
Нефункциональные требования.
Приблизительные оценки.
Шаг 2: предложить высокоуровневый дизайн и получить одобрение.
Проектирование запросов API.
Модель данных.
Высокоуровневый дизайн.
Шаг 3: детали дизайна.
Потоковая и пакетная обработка.
Время.
Окно агрегации.
Гарантии доставки.
Дедупликация данных.
Масштабирование системы.
Отказоустойчивость.
Контроль и корректность данных.
Альтернативный вариант дизайна.
Шаг 4: итоги.
Краткий обзор главы.
Ссылки.
Глава 7. Система бронирования отелей.
Шаг 1: понять задачу и определить масштаб решения.
Нефункциональные требования.
Приблизительные оценки.
Шаг 2: предложить высокоуровневый дизайн и получить одобрение.
Дизайн API.
Модель данных.
Высокоуровневый дизайн.
Шаг 3: детали дизайна.
Улучшенная модель данных.
Конкурентность.
Масштабируемость.
Согласованность данных между сервисами.
Шаг 4: итоги.
Краткий обзор главы.
Ссылки.
Глава 8. Распределенный сервис электронной почты.
Шаг 1: понять задачу и определить масштаб решения.
Нефункциональные требования.
Приблизительные оценки.
Шаг 2: предложить высокоуровневый дизайн и получить одобрение.
Общие сведения об электронной почте.
Традиционные почтовые серверы.
Распределенные почтовые серверы.
Шаг 3: детали дизайна.
База метаданных.
Гарантированность доставки электронной почты.
Поиск.
Масштабируемость и доступность.
Шаг 4: итоги.
Краткий обзор главы.
Ссылки.
Глава 9. Объектное хранилище, подобное S3.
Общие сведения о хранилищах данных.
Терминология.
Шаг 1: понять задачу и определить масштаб решения.
Нефункциональные требования.
Приблизительные оценки.
Шаг 2: предложить высокоуровневый дизайн и получить одобрение.
Высокоуровневый дизайн.
Загрузка объекта.
Скачивание объекта.
Шаг 3: детали дизайна.
Хранилище данных.
Модель метаданных.
Вывод списка объектов в бакете.
Версионирование объектов.
Оптимизация загрузки больших файлов.
Сборка мусора.
Шаг 4: итоги.
Краткий обзор главы.
Ссылки.
Глава 10. Лидерборд в реальном времени.
Шаг 1: понять задачу и определить масштаб решения.
Функциональные требования.
Нефункциональные требования.
Приблизительные оценки.
Шаг 2: предложить высокоуровневый дизайн и получить одобрение.
Дизайн API.
Высокоуровневый дизайн.
Модель данных.
Шаг 3: детали дизайна.
Обращаться или нет к облачному провайдеру.
Масштабирование Redis.
Альтернативное решение: NoSQL.
Шаг 4: итоги.
Краткий обзор главы.
Ссылки.
Глава 11. Платежная система.
Шаг 1: понять задачу и определить масштаб решения.
Функциональные требования.
Нефункциональные требования.
Приблизительные оценки.
Шаг 2: предложить высокоуровневый дизайн и получить одобрение.
Поток входящих платежей.
Поток исходящих платежей.
Шаг 3: детали дизайна.
Интеграция с PSP.
Реконсиляция данных.
Устранение задержек при обработке платежей.
Взаимодействия между внутренними сервисами.
Обработка неуспешных платежей.
Доставка «точно один раз».
Согласованность состояний сервисов.
Безопасность платежей.
Шаг 4: итоги.
Краткий обзор главы.
Ссылки.
Глава 12. Цифровой кошелек.
Шаг 1: понять задачу и определить масштаб решения.
Функциональные требования.
Приблизительные оценки.
Шаг 2: предложить высокоуровневый дизайн и получить одобрение.
Дизайн API.
Шардинг резидентного хранилища.
Распределенные транзакции.
Паттерн Event Sourcing («источники событий»).
Шаг 3: детали дизайна.
Повышение производительности паттерна Event Sourcing.
Надежная и высокопроизводительная архитектура на основе паттерна Event Sourcing.
Распределенные источники событий.
Шаг 4: итоги.
Краткий обзор главы.
Ссылки.
Глава 13. Фондовая биржа.
Шаг 1: понять задачу и определить масштаб решения.
Нефункциональные требования.
Шаг 2: предложить высокоуровневый дизайн и получить одобрение.
Основные сведения о бизнесе.
Высокоуровневый дизайн.
Дизайн API.
Модели данных.
Шаг 3: детали дизайна.
Производительность.
Паттерн Event Sourcing.
Высокая доступность.
Отказоустойчивость.
Алгоритмы согласования.
Детерминированность.
Издатель рыночных данных.
Справедливость распределения рыночных данных.
Многоадресная рассылка.
Колокация.
Сетевая безопасность.
Шаг 4: итоги.
Краткий обзор главы.
Ссылки.
Послесловие.

Купить .





Теги: учебник по информатике :: информатика :: компьютеры :: Сюй :: Лэм