Отзыв о книге Алекса Сюй "System Design. Подготовка к сложному интервью"
Прочитал недавно книгу Alex Xu “System Design Interview”. Книгу эту приметил уже давно и ранее читал некоторые главы в англоязычном издании. Но тут узнал, что есть русскоязычное бумажное издание, и купил книгу, чтобы пополнить библиотеку в офисе.
![](/post/2022/system-design-interview/featured_hu3d7ebfb200d26c35c8199118c4e959f3_1013813_1200x2500_fit_q75_h2_lanczos.webp)
Прочитал недавно книгу Alex Xu “System Design Interview”. Книгу эту приметил уже давно и ранее читал некоторые главы в англоязычном издании. Но тут узнал, что есть русскоязычное бумажное издание, и купил книгу, чтобы пополнить библиотеку в офисе.
Начинается книга с обзора базовых приёмов проектирования информационных систем, которые должны обслуживать миллионную аудиторию пользователей: вертикальное и горизонтальное масштабирование, балансировщики трафика, кеши, репликация и шардирование баз данных, CDN, очереди сообщений.
Отдельная вводная глава посвящена вопросу эффективного выведения приблизительных оценок при проектировании. Приводится таблица продолжительности типичных компьютерных операций, из которой мы, например, узнаём, что последователь чтение из памяти 1 Мб занимает 250 мкс, а с жесткого диска в 120 раз медленнее - за 30 мс. Знать “на зубок” эту таблицу вряд ли нужно, но как шпаргалка, может пригодиться.
Завершает вводные главы инструкция по удачному прохождению собеседования по проектированию IT-систем, состоящая из 4 шагов.
-
Шаг 1 - “Понять задачу и определить масштаб решения”. На этом шаге мы должны задать исчерпывающее множество уточняющих вопросов, чтобы понять, какую систему надо спроектировать и прояснить неоднозначные моменты. Важно узнать целевые числовые метрики.
-
Шаг 2 - “Предложить общее решение и получить согласие”. На этом шаге предлагается подготовить первоначальную обобщенную архитектуры решения и согласовать её с интервьюером. Когда общая архитектура согласована, то переходим к шагу 3.
-
Шаг 3 - “Глубокое погружение в проектирование”. Время собеседования не бесконечно, и на этом шаге стоит сконцентрироваться только на ключевых аспектах предлагаемого решения. Такие, например, может указать интервьюер на шаге 2.
-
Шаг 4 - “Подведение итогов”. Тут можно обсудить достоинства и недостатки предложенного решения, оценить альтернативы, обсудить эксплуатационные вопросы.
Последующие главы представляют собой проектирование различных видов информационных систем в формате интервью, следующих описанным выше 4 шагам. Системы предлагается проектировать разнообразные: ограничитель трафика, системы мгновенного обмена сообщений, аналог YouTube или Google Drive.
Формат, на мой взгляд, выбран удачный. Типов проблем, которые приходится решать при разработке распределённых систем, много. Придумать же какой-то один правдоподобный пример информационной системы, который бы собрал их все, и протянуть этот пример через всю книгу весьма сложно. Тут же при рассмотрении в каждой главе проектирования системы определённого класса у автора появляется возможность лаконично вписать в повествование описание важных и интересных теоретических и практических вещей. Так при разговоре о проектировании хранилища “ключ-значение” читатель знакомится с CAP-теоремой, векторными часами, моделями согласованности данных, согласованным хешированием, базовыми идеями, которые используются в таких СУБД как Cassandra, DynamoDB, BigTable. В главе про проектирование системы автозаполнения поисковых запросов читатель может узнать о такой структуре данных как Trie, а в главе, где проектируется аналог WhatsApp, о плюсах и минусах long polling и WebSocket.
Конечно, не стоит ожидать, что описание многих вещей будет подробным. Книга даёт лишь указание “Эй, читатель! Есть вот такая штука, обрати на неё внимание, но дальше копай сам”. Хватит ли после прочтения книги у неподготовленного читателя знаний на то, чтобы успешно проектировать подобные системы? Скорее всего, нет. Но базис книга заложить может.
Завершает книга главой с названием “Век живи - век учись”, со ссылками на описание архитектур существующих систем и технических блогов известных компаний. Во многом список совпадает вот с этим - https://github.com/donnemartin/system-design-primer#company-engineering-blogs.
Вообще, во время карьеры разработчика/архитектора может оказаться не так много моментов, когда у него появится возможность спроектировать что-то новое, масштабное. Поэтому изучение архитектуры существующих успешных систем - это, по сути, один из немногих способов, как получить знания, которые помогут в будущем, когда разработчик/архитектор в реальности столкнётся с задачей проектирования.
Ещё один способ отточить свои навыки проектирования - это участие в архитектурных катах. Это специализированные соревнования, на которых команды выясняют, кто лучше сможет спроектировать, описать и презентовать архитектуру предложенной организаторами системы. Вот, например, соревнования от O’Reilly - https://www.youtube.com/watch?v=EicfaYa5nDg
Тема собеседований по системному дизайну мне интересна уже продолжительное время. Последние года два-три при найме архитекторов, руководителей команд разработки, ведущих программистов я в ходе собеседования предлагаю кандидатам эволюционно развивать архитектуру некоторой вымышленной информационной системы.
Так шаг за шагом в ходе интервью мы решаем озвучиваемые проблемы и обсуждаем вопросы масштабирования компонентов системы, балансировки, распредлённых транзакций и блокировок, меняем одни способы интеграции на другие и т.д.
Вообще, наблюдая за ребятами, с которыми работаю вместе, я замечаю, что далеко не все понимают, как в целом выглядят и функционируют системы, которые мы разрабатываем. Как обеспечивается то, что системы обслуживают миллионы клиентов в день, как десятки тысяч одновременно работающих пользовательских сессий распределяются по разным серверам и т.д.
Это немного печалит, но мы не стоим на месте и запустили процесс проведения архитектурных вебинаров, в рамках которого на регулярной основе команда архитекторов проводит для команд проектов обзоры текущей архитектуры разрабатываемых систем, объясняет что, почему и как изменяется.
При составлении индивидуальных планов развития сотрудников я регулярно предлагал ребятам взглянуть в сторону темы “System design” и делился ссылкой на https://github.com/donnemartin/system-design-primer. Теперь буду ещё и книгу “System Design Interview” предлагать прочитать.
Пока писал заметку вспомнил, что у подкаста “Подлодка” был выпуск посвящённый системного дизайну. Держите ссылку - https://podlodka.io/224
Большинство глав в книге заканчивалось одной и той же фразой. Это выглядело немного странно. Закончу и я этот пост ей же :-)
Поздравляем, вы проделали длинный путь и можете гордиться собой. Отличная работа!