Какая была нагрузка по количеству пользователей в день или час

Что проверяют

Работали ли вы с реальной нагрузкой и понимаете ли, откуда берутся цифры. Интервьюеру важен не размер, а то, умеете ли вы перевести «пользователей в день» в запросы в секунду и назвать узкое место. Следом почти всегда спрашивают: что было на пике и как вы это измеряли?

Как отвечать

Отвечайте цифрами из своего проекта и сразу связывайте их между собой:

• аудитория: уникальные пользователи в сутки (DAU) и сколько запросов делает один пользователь за сессию;
• средний и пиковый RPS: 10 000 пользователей по 20 запросов дают около 200 000 запросов в сутки, это в среднем 2-3 RPS. Пик обычно в несколько раз выше среднего, и инфраструктуру считают под него;
• откуда цифры: метрики в Prometheus и Grafana, логи Nginx, APM-инструменты вроде Sentry. Если цифры по памяти, так и скажите;
• стек и узкое место: сколько воркеров Gunicorn или Uvicorn, во что упирались (база, внешний API, CPU на сериализации) и что сделали: кеш в Redis, пул соединений через PgBouncer, вынос тяжёлых операций в Celery, индексы по медленным запросам из pg_stat_statements;
• проверка: гоняли ли нагрузочные тесты в Locust или k6 и до какого RPS система держала задержку p95 в норме.

Если нагрузка была скромной, не стесняйтесь: «сотни пользователей в день, внутренний сервис» тоже нормальный ответ. Добавьте, как бы вы его масштабировали и что сломалось бы первым.

Где спотыкаются

Путают пользователей в сутки, одновременных пользователей и RPS. «Тысяча одновременных пользователей» без пояснения, как часто они шлют запросы, ничего не говорит о нагрузке.

Называют круглые большие числа, а на уточнении про p95, число воркеров или объём базы теряются. Интервьюер быстро понимает, что цифры придуманы.

Говорят только о среднем времени отклика. Среднее скрывает хвост, а жалобы пользователей обычно про p95 и p99, поэтому называйте перцентили.