Оценки на интервью
Прикидки на салфетке окупаются на интервью лишь когда число меняет дизайн. Оценивай важный масштаб, читай, хочет ли интервьюер математику или вывод, и превращай оценки в ёмкость — серверы, хранилище, полосу — чтобы архитектуру форсировала арифметика, а не утверждение.
Два кандидата получают один промпт. Первый заполняет доску арифметикой — средняя длина твита в байтах, точное число секунд в сутках, шестизначный QPS — и через сорок минут имеет красивый набор чисел и никакой архитектуры. Второй пишет четыре числа, говорит «300K read QPS, значит одна база отпадает — нужен кэш и fan-out путь чтения (разветвление записи по репликам/лентам подписчиков); хранение доминирует медиа на ~50 PB, значит объектное хранилище плюс CDN» и начинает рисовать. Та же математика — противоположный итог. Первый сделал оценку целью; второй сделал её рычагом — каждое число существовало лишь чтобы форсировать решение о следующей коробке.
Оценка — средство, не шоу
Ты уже знаешь, как оценивать, из урока «прикидки на салфетке» в юните масштабируемости: степени двойки, числа задержек Джеффа Дина, округление до одной значащей цифры, считать на пик. Этот урок — про то, когда и зачем применять этот навык внутри интервью, потому что самый частый провал оценки на интервью — не плохая арифметика. Это арифметика, которая ничего не решает.
Число заслуживает места на доске, только если оно изменило бы дизайн. «Сервис хранит около 2 КБ на запись» — мелочь, пока не домножишь и не обнаружишь, что это 5 PB за окно хранения — теперь это решение: объектное хранилище, не реляционная БД; ярусное хранение, не всё-горячее. Ход сеньора — оценивать к выводу: каждая цифра — вопрос («это влезает в одну коробку или нужен флот?»), ответ на который выбирает следующий компонент. Если число не меняет ни одного решения — не считай его.
Какие числа меняют дизайн
Небольшой набор оценок переворачивает архитектуры. Научись тянуться к ним и пропускать остальное:
- Read QPS на пике. Решает, может ли одна primary-база обслуживать чтения (низкие тысячи QPS) или нужны реплики, кэш или fan-out. Обычно это первое число, меняющее дизайн.
- Write QPS на пике. Одна primary держит низкие тысячи записей/с; десятки тысяч форсируют шардинг или другое хранилище. Это число решает, прост или сложен слой данных.
- Хранилище за окно хранения, разбитое по классам данных. Текст против медиа часто отличаются в 100×; доминирующий класс выбирает технологию хранения (реляционка против объектного хранилища + CDN).
- Размер горячего рабочего набора. Если горячий набор влезает в RAM одного узла (~256 ГБ), работает один узел кэша; выше — шардишь кэш.
- Полоса egress на пике. Пиковый read QPS × средний размер ответа говорит счёт за CDN и влезет ли в один NIC.
Вместе эти пять чисел покрывают каждый ярус, где архитектура способна согнуться: read QPS отмеряет кэш, write QPS решает шардинг, хранилище выбирает класс данных, горячий набор отмеряет узлы кэша, а полоса выбирает CDN. Пропусти любое — и утверждаешь решение без арифметики за ним: интервьюер это заметит. Заметь: они один-к-одному ложатся на точки давления дизайна — слой данных, слой кэша, слой доставки. Ты оцениваешь четыре-пять чисел на границе между «одной коробкой» и «флотом», потому что там архитектура и гнётся.
▸Почему это работает
Зачем вообще оценивать на интервью, а не просто заявить «масштаб большой, значит шардим»? Потому что интервьюер проверяет, обоснованы твои решения или взяты по культу карго. Сказать «добавь кэш» может каждый. Сигнал — можешь ли ты сказать «300K read QPS против хранилища на ~5K QPS на узел значит ~60 реплик чтения или, лучше, кэш, гасящий 95% чтений, и тогда узлов нужна горстка». Число — вот что отделяет реального инженера от того, кто декламирует паттерны. Оно же защищает от перестройки: оценка, говорящая «на самом деле тут всего 200 QPS», — вот что останавливает тебя от шардинга базы, что спокойно влезает в одну коробку — провал золочения из урока требований, теперь пойманный арифметикой.
Читай интервьюера: математика или вывод?
Тонкий навык интервью — калибровать, сколько арифметики показывать. Интервьюеры лежат на спектре, и тот же подробный вывод, что один хочет, ровно то, что другого вгоняет в «давайте дальше».
- Некоторые хотят видеть механику — они проверяют, что ты реально умеешь считать, переводить сутки в секунды, применять пиковый множитель, честно округлять. Покажи работу.
- Многие хотят вывод — они верят, что ты умножать умеешь, и хотят знать, что число значит для дизайна. Дай результат и решение, которое оно форсирует, на одном дыхании: «~10K записей/с на пике, это за пределом одной primary, значит шардю по user ID».
Лови подсказки. Если интервьюер подаётся вперёд и спрашивает «как ты это получил?» — он хочет вывод. Если кивает и косится на часы — давай выводы и копи время на дизайн и deep-dive — части, что реально различают кандидатов. Потратить пятнадцать минут на вывод числа до трёх значащих цифр — само по себе красный флаг: это сигналит, что ты не отличаешь нагруженный расчёт от тщеславного, и сжигает бюджет, нужный на сложную часть.
От оценки к ёмкости
Окупаемость оценки — ёмкость: превращение числа нагрузки в количество серверов, гигабайт и гигабит, которые можно положить на схему. Перевод механический, как только есть пропускная способность на узел.
серверы = пиковый QPS / QPS на узел (округлить вверх, добавить запас)
хранилище = размер объекта × темп записи × окно хранения (разбить по классам)
полоса = пиковый read QPS × средний размер ответа
кэш = размер горячего набора → влезает в RAM узла? иначе шардьПример, на основе оценки design-a-Twitter из юнита масштабируемости: ~10K записей/с на пике, ~300K чтений/с на пике, ~50 PB медиа за 5 лет. Переводим:
- App/read серверы. Если один узел тянет ~5K read QPS, 300K / 5K = 60 узлов — но большинство чтений должно идти в кэш, поэтому реальное число — «кластер кэша с горячим набором ленты плюс горстка origin-узлов на промахи». Сырые 60 — это верхняя граница, оправдывающая кэш.
- Путь записи. 10K записей/с за пределом комфортных низких тысяч одной primary, значит шардь — оценка только что отмерила слой данных. Это число форсировало самое сложное решение во всём дизайне, и ты получил его до того, как что-то нарисовал.
- Хранилище. ~50 PB медиа → объектное хранилище (класса S3) за CDN, не база; ~0,5 PB текста → шардированное реляционное или wide-column хранилище. Оценка сказала две разные технологии хранения, что нужны дизайну.
- Полоса. 300K чтений/с × ~5 КБ = ~1,5 ГБ/с ≈ 12 Гбит/с egress — норм через CDN-флот, но кладёт реальную стоимость на счёт и говорит, что один NIC на 10 Гбит/с не обслужит.
▸Частая ошибка
Ошибка оценки, что тихо ломает дизайн, — считать на среднее и игнорировать пик — та же ловушка, что в юните масштабируемости, но на интервью кусает сильнее, потому что интервьюер её ищет. Ты считаешь 3 000 записей/с в среднем, объявляешь одну primary нормой, а интервьюер спрашивает «а вечерний пик?» — при 3× это 9–10K записей/с, за пределом одной primary, и весь слой данных был неверен. Всегда неси пиковый множитель (начни с 3× для consumer-приложений), и помни ловушку второго порядка: во время инцидента клиентские ретраи добавляют нагрузку ровно на пике, так что система, посчитанная под среднее, не просто деградирует (brownout — частичный отказ под нагрузкой) — она входит в шторм ретраев и валится. Оценивай пик, и оценивай его с ретраями в уме.
Посреди интервью ты установил ~8 000 записей/с на пике против хранилища, где одна primary комфортно тянет ~3 000 записей/с. Что правильно сказать дальше?
Интервьюер быстро кивает сквозь твою математику QPS и косится на часы. Что это сигналит и как подстроиться?
На интервью число принадлежит доске, только если оно _______ дизайн — каждая цифра должна отвечать на вопрос вроде «одна коробка или флот?», ответ на который выбирает следующий компонент; арифметика, что ничего не решает, — потраченное время.
- 01Какие числа меняют дизайн и почему оценивать именно их?
- 02Как читать, хочет ли интервьюер математику или вывод?
- 03Как превратить оценку в ёмкость и в чём ловушка пика?
Ты узнал, как оценивать, в юните масштабируемости; этот урок — когда и зачем внутри интервью. Главное правило: оценивай только числа, что меняют дизайн — пиковый read QPS, пиковый write QPS, хранилище за окно хранения (по классам данных), размер горячего набора и пиковую полосу — потому что каждое на границе между «одной коробкой» и «флотом», где архитектура и гнётся. Каждая цифра должна отвечать на вопрос, ответ на который выбирает следующий компонент; арифметика, что ничего не решает, — потраченное время. Читай интервьюера: одни хотят механику (покажи работу), большинство хочет вывод (назови число и решение, что оно форсирует, на одном дыхании), а выводить до трёх значащих цифр, когда хотят дальше, — красный флаг. Наконец, превращай оценки в ёмкость — серверы = пиковый QPS / на-узел, хранилище = размер × темп × окно, полоса = QPS × размер ответа — чтобы коробки на схеме форсировала арифметика, а не утверждение. И всегда считай на пик, не на среднее, с штормом ретраев в уме: число «~10K записей/с на пике» — то, что форсирует шардированный слой данных, самое сложное решение в дизайне, до того как нарисована коробка. Теперь, когда садишься считать, спрашивай для каждого числа: какое решение дизайна оно форсирует? Не можешь ответить — не считай.
Практика
Начни сверху. Задачи идут от простого к сложному: вспомнить факт, применить к случаю, затем senior-уровень. Открой, попробуй, потом открой ответ.
Что-то непонятно?
Задай вопрос по этому уроку. Вопросы анонимны и попадают напрямую автору — урок станет лучше.
Примени это
Примени этот урок в реальном проекте.