sottoЗачем это на интервью
Оценка на салфетке проверяет не арифметику, а чувство масштаба: понимаете ли вы, идёт ли речь о тысяче запросов в секунду или о миллионе, помещаются ли данные в память одной машины, нужен ли вообще шардинг. От ответа на эти вопросы зависит вся дальнейшая архитектура, поэтому оценку делают в начале обсуждения, а не в конце.
Интервьюер не ждёт точности. Ошибка вдвое несущественна, ошибка на три порядка — приговор, потому что она приводит к неверному классу решения. Проговаривайте допущения вслух и округляйте агрессивно: 86 400 секунд в сутках — это 10 в пятой, миллион запросов в сутки — примерно 12 в секунду.
Полезная привычка — считать сверху вниз: от аудитории к действиям, от действий к запросам, от запросов к данным. И сразу отделять средние значения от пиковых, потому что проектируют под пик.
Порядки, которые стоит помнить
Точные числа никто не спрашивает, но порядки величин должны быть в голове, потому что именно они определяют, что дорого, а что нет.
Задержки: обращение к оперативной памяти — порядка ста наносекунд; случайное чтение с SSD — десятки-сотни микросекунд; обращение к вращающемуся диску — единицы-десятки миллисекунд; round trip внутри дата-центра — около половины миллисекунды; round trip между континентами — порядка ста-двухсот миллисекунд, и это ограничено скоростью света, то есть не оптимизируется в принципе.
Ключевые соотношения важнее самих чисел: память быстрее SSD примерно в тысячу раз, SSD быстрее вращающегося диска примерно в сто раз, а межконтинентальный запрос дороже локального в сотни раз. Отсюда прямые проектные выводы: кэш в памяти окупается почти всегда, случайный доступ к диску — то, чего избегают, а география пользователей требует CDN или региональных развёртываний, потому что скорость света обойти нельзя.
Ёмкости: строка данных о заказе — сотни байт, JSON-документ — единицы килобайт, сжатая фотография — сотни килобайт, минута видео — десятки мегабайт. Разница между текстом и медиа — три-четыре порядка, поэтому в задачах с картинками и видео объём почти всегда определяется медиа, а метаданные можно не считать вовсе.
От аудитории к запросам
Стандартная цепочка: количество активных пользователей в сутки → сколько целевых действий совершает один пользователь → сколько это запросов в сутки → делим на 86 400 и получаем средний QPS → умножаем на пиковый коэффициент.
Пиковый коэффициент обычно берут от двух до пяти в зависимости от того, насколько трафик привязан к времени суток и к событиям. Сервис с равномерной мировой аудиторией ближе к двум; сервис одной страны с вечерним пиком — ближе к четырём-пяти; а если бывают всплески от рассылок или распродаж, их закладывают отдельно.
Пример на десять миллионов активных пользователей в сутки, каждый совершает двадцать действий: двести миллионов запросов в сутки, делим на сто тысяч секунд — примерно две тысячи запросов в секунду в среднем, при пиковом коэффициенте три — около шести тысяч в пике. Уже из этого числа многое следует: это заведомо не одна машина, но и не экзотика — обычный горизонтально масштабируемый сервис.
Отдельно оценивают соотношение чтения и записи. Для ленты или каталога оно легко составляет сто к одному, и тогда архитектура определяется чтением: кэш, реплики на чтение, денормализованные представления. Для системы приёма событий соотношение обратное, и главным становится приём записи. Не спросить про это соотношение — типичная ошибка на интервью.
Объём данных и трафик
Хранение считают так: число новых записей в сутки, умноженное на размер записи, умноженное на горизонт хранения, умноженное на коэффициент репликации. Последний множитель забывают чаще всего, а он обычно равен трём — и сразу утраивает ответ. Плюс накладные расходы на индексы, которые для активно индексируемых таблиц сопоставимы с самими данными.
Пример: сто миллионов сообщений в сутки по одному килобайту — это сто гигабайт в сутки, около тридцати шести терабайт в год, а с тройной репликацией — порядка ста терабайт в год. Из такой оценки сразу следует разговор о партиционировании по времени, о переносе холодных данных в дешёвое хранилище и о сроке жизни данных.
Пропускную способность считают как QPS, умноженный на средний размер ответа. Шесть тысяч запросов в секунду по двадцать килобайт — это порядка гигабита в секунду, что уже требует внимания к балансировке и к CDN. Здесь же полезно вспомнить про сжатие: текст и JSON сжимаются в несколько раз почти бесплатно.
Память под кэш оценивают через рабочее множество, а не через весь объём данных. Распределение обращений обычно сильно неравномерное, поэтому небольшая доля данных даёт основную часть попаданий — именно это делает кэш эффективным. Практический вопрос звучит так: сколько стоит держать в памяти самые горячие данные за последние сутки, и помещается ли это в разумное число машин.
Куда упрётся первым
Смысл оценки не в числах, а в выводе: какой ресурс закончится раньше остальных. Именно это и хочет услышать интервьюер.
Типичная последовательность узких мест в веб-системах: сначала база данных (обычно запись и блокировки, а не чтение), затем внешние синхронные вызовы, затем сеть, и лишь потом процессор приложения. Приложение почти всегда масштабируется горизонтально проще всего, поэтому оно редко оказывается настоящим ограничением.
Ошибка, которую стоит назвать вслух: оптимизировать то, что удобно измерить, а не то, что ограничивает. Загрузка CPU на сервере приложений в 30% при полностью загруженном пуле соединений к базе означает, что добавление машин ничего не даст.
Полезная закономерность — деградация под нагрузкой не линейна. По мере приближения утилизации к ста процентам время ожидания в очереди растёт стремительно, поэтому системы проектируют с запасом: работать на девяноста процентах утилизации означает, что небольшой всплеск даёт непропорционально большую задержку. Отсюда же практический совет наблюдать насыщение (длину очередей), а не только утилизацию.
Как отвечать на собеседовании
Считайте вслух и записывайте допущения: сколько пользователей, сколько действий, какой пиковый коэффициент, какое соотношение чтения и записи. Интервьюер оценивает ход рассуждения, а не итоговое число, и явное допущение всегда лучше молчаливого.
Округляйте безжалостно и держите опорные числа: сутки — сто тысяч секунд, репликация — множитель три, пик — множитель от двух до пяти. Это освобождает голову для содержательной части.
Обязательно спрашивайте про соотношение чтения и записи и про горизонт хранения — без них оценка бессмысленна, а сам вопрос показывает опыт.
И главное — завершайте оценку выводом, а не числом: «около шести тысяч запросов в секунду в пике и сто терабайт в год, значит одна база не справится с записью — нужно партиционирование по времени и отдельная модель чтения». Число без архитектурного следствия не стоит ничего.