Сайзинг на собесе: зачем вообще считать QPS и хранилище

Formula-based estimation проверяет не арифметику. Проверяют, умеет ли кандидат превратить расплывчатое «спроектируйте систему уведомлений» в конкретные числа, от которых зависят архитектурные решения.

Базовая цепочка: DAU умножаем на среднее число действий в день, делим на 86 400 секунд в сутках — получаем средний QPS. Пиковый трафик обычно в 3–10 раз выше среднего, в зависимости от того, насколько события системы размазаны по дню или собраны в часы пик.

Для хранилища отдельная формула: количество записей умножаем на размер одной записи, умножаем на срок хранения и на число реплик. Если забыть про реплики — получится красивое число, которое разойдётся с реальным железом в несколько раз.

-- пример: 10 млн DAU, 5 уведомлений в день -- avg QPS = 10_000_000 * 5 / 86400 ~ 579 -- peak QPS (x5) ~ 2900 -- storage: 10kk * 5 * 200 bytes * 30 days * 3 replicas

Частая ловушка — взять пиковый коэффициент «на глаз» и не обосновать его природой трафика. Если система глобальная и у пользователей разные часовые пояса, пик размазан и коэффициент ближе к 3. Если аудитория в одном часовом поясе и события привязаны к конкретному времени (утренняя рассылка, старт рабочего дня) — пик может быть выше 10. На собесе ждут не число, а объяснение, откуда оно взялось.

Цифра без объяснения — просто цифра. На сеньорском собесе ценится не точность прикидки, а то, что из неё следует: нужен ли шардинг, выдержит ли один инстанс Redis, нужна ли очередь перед БД.

senior·base — что спрашивают на самом деле

В этом посте были ссылки, но мы их удалили по правилам Сетки