Обзор фреймворка для прохождения интервью из книги “System Design Interview: An Insider’s Guide”

Сегодня я участвовал во встрече книжного клуба { между скобок }, на которой мы разбирали 2 главы из книги “System Design Interview” за авторством Alex Xu. А точнее мы разбирали вторую и третью главы, в которых автор рассказывает про приблизительные оценки (back-of-the-envelope estimation) и делится подходом для прохождения интервью по системному дизайну (a framework for system design interviews). Эти главы достаточно интересны, чтобы кратко рассмотреть их в этой статье, а всю первую половину книги я рассмотрел в следующей статье.

Back-of-the-envelope estimation

Эта глава совсем мала, так как в ней автор приводит всего три таблички и один пример приблизительного расчета нагрузки на Twitter в виде query per second и storage, необходимого для хранения твитов и медиа.

Первая табличка проводит соответствие между степенями двойки, которыми все измеряется в мире компьютеров и степенями десятки, которые привычны для людей, одновременно приводятся названия единиц на примере байтов. Кстати про то, что один байт — это восемь битов автор тоже упоминает. Приведем этот перечень
— 2⁰=1, 1 byte,
— 2¹⁰≈10³ byte, 1 Kilobyte, 1 KB
— 2²⁰ ≈10⁶ byte, 1 Megabyte, 1 MB
— 2³⁰ ≈10⁹ byte, 1 Gigabyte, 1 GB
— 2⁴⁰ ≈10¹² byte, 1 Terabyte, 1 TB
— 2⁵⁰ ≈10¹⁵ byte, 1 Petabyte, 1 PB
— 2⁶⁰ ≈10¹⁸ byte, 1 Exabyte, 1 EB

Вторая табличка называется “Latency numbers every programmer should know” и при ее анонсе идет отсылка к Jeff Dean, Google Senior Fellow, который опубликовал ее изначально в 2010.

Но тут мы пожалуй приведем более новую версию из rule-of-thumb-latency-numbers-letter, которая тоже опубликована Google в их материалах для SRE. Из этой таблицы видна драматическая разница в таймингах разных операций.

Рис.1 “Latency Numbers Everyone Should Know”

Ну и последняя табличка в этой главе посвящена тому, как считать показатели доступности (availability), а именно если наш сервис должен быть доступен X, то сколько времени он может быть недоступен. Но сначала стоит привести единицы времени, которые достались нам от шумеров и используют шестидесятеричная система счисления, которая очень “удобна”

— 1 секунда
— 1 минута = 60 секунд
— 1 час = 60 минут = 3600 секунд
— 1 сутки = 1440 минут = 86400 секунд

А теперь пришло время привести табличку с числами доступности

— SLA=99%, недоступность 1%, 14.4 min per day, 3.65 day per year
— SLA=99.9%, недоступность 0.1%, 1.44 min per day, 0.365 day per year
— SLA=99.99%, недоступность 0.01%, 8.64 sec per day, 52.6 min per year
— SLA=99.99%, недоступность 0.001%, 0.864 sec/day, 5.26 min/year
— SLA=99.999%, недоступность 0.0001%, 0.0864 sec/day, 31.56 sec/year

Дальше автор приводит пример расчетов и на этом глава заканчивается. Гораздо интереснее следующая глава

A framework for system design interviews

Фреймворк, который предлагает автор состоит из четырех шагов, что приведены на рисунке ниже.

Рис.2 “Four step process for effective system design interview”

Давайте кратко обсудим каждый из указанных шагов

1. Понять проблему и ограничить то, что именно мы должны спроектировать . Здесь надо задавать правильные вопросы для того, чтобы понять что входит в scope задачи и, что важнее, что в него не входит. По итогам этого шага мы должны четко понимать что должна уметь делать наша система и как ее будут использовать (сколько людей и насколько интенсивно)
2. Предложить высокоуровневый дизайн и согласовать его с интервьюером. На этом шаге можно пойти от конкретных сценариев системы и нарисовать ее верхнеуровневую схему и обсудить ее с интервьюером. Здесь же можно приблизительно прикинуть нагрузку, используя подходы из предыдущей главы. По итогам этого шага у нас будет упрощенная архитектура системы, где видны ее основные компоненты.
3. Провести полноценный дизайн нашей системы. На этом шаге происходит самое интересное. Тут важнее всего понять какие части системы стоит рассмотреть глубоко, а какие не столь интересны. У вас могут быть свое мнение, но хорошо его проверить об интервьюера. Эта часть сильно зависит от уровня кандидата — например, с senior кандидатами интервьюеры могут обсудить тут bottlenecks и performance issues. В любом случае здесь важно четко идти по определенным темам и не отвлекаться на второстепенные детали.
4. Завершение интервью. В последней части интервьюер может задать дополнительные вопросы или дать кандидату самому сделать финальные ремарки по получившемуся дизайну.

Если смотреть на разбивку этих частей по времени, то видно, что второй и третий шаг являются самыми важными в этом интервью. На этом эти главы заканчиваются.

P.S.

Наше обсуждение глав этой книги можно посмотреть в представленном ниже видео.

P.P.S.

Автор книги рассказал про свой четырехшаговый процесс для прохождения интервью, который является достаточно простым и общим. Если интересно посмотреть как этот процесс выглядит в Tinkoff, то можно почитать мои статьи, где я подробно про это рассказываю:

— Статья про System Design Interview в общем
—Статья про то как оценивается System Design Interview
— Публичное System Design Interview на C++ Russia 2022
— Публичное System Design Interview на конференции ArchDays 2022
— Как подготовиться и пройти System Design Interview
— Обзор первой половины “System Design Interview: An Insider’s Guide”
— Обзор второй половины “System Design Interview: An Insider’s Guide”

И для затравки приведу пример шагов нашего процесса System Design Interview

Рис.3 “Фреймворк для System Design, что принят в Tinkoff”