Sanity-check и оценка: вопросы для собеседования (часть 2)

Если продукт ограничен одной страной, то `MAU` не должен превышать число потенциальных пользователей в этой стране. Значение выше `upper bound` обычно означает ошибку в `units` (например, устройства вместо людей), дубли между платформами или неверный метод подсчёта уникальности. Такой грубая прикидка `order of magnitude` чек помогает быстро поставить под сомнение отчёт до обсуждения причин роста. Затем нужно уточнить определение активного пользователя и ключ дедупликации.

Если неизвестен `DAU`, вы всё равно знаете, что `DAU ≤ MAU`, значит максимум пушей в день ограничен 3 × 10 млн = 30 млн. Это грубый `upper bound`, но он сразу отсеивает фантастические значения при данных `constraints`. Дальше можно уточнять ожидание через `assumptions` о `DAU/MAU` и фактической частоте отправок.

Сначала оцените число платящих: 200 тыс `DAU` × 2% ≈ 4 тыс платящих в день. Затем умножьте на 500 ₽ и получите около 2 млн ₽ в день. Такой расчёт полезен как `sanity-check`: он быстро показывает, на сколько нулей отличается итог. Если в результате получились сотни миллионов при таких входных, это явный `order of magnitude` сбой.

2 млрд / 50 тыс ≈ 40 тыс секунд, это около 11 часов по грубая прикидка. Такой `order of magnitude` чек помогает не перепутать секунды, часы и дни в планировании. Если оценка выходит на месяцы, скорее всего вы забыли про параллелизм или ошиблись в `units`. После грубой оценки можно добавить `upper bound` на непредвиденные простои.

При фиксированном каталоге максимум уникальных `sku` за день ограничен размером каталога. Значение выше этого `upper bound` обычно появляется из-за неверного `units` уровня уникальности (например, считаете `sku_id` вместе с `store_id`) или из-за дублей после джойна. грубая прикидка проверка `constraints` помогает быстро локализовать такие баги. После исправления стоит сверить ключи агрегации и логику `dedup`.