Делали ли расчеты по предстоящим нагрузкам при проектировании системы?
Что проверяют
Умеете ли вы до написания кода прикинуть порядок нагрузки и понять, где система упрётся первой. Следом обычно просят пересчитать на ходу: сколько нужно воркеров и соединений с базой под названный трафик.
Как отвечать
Каркас стройте на своём проекте: какая была задача, какие цифры вы взяли за основу, что посчитали и что подтвердилось на нагрузочном тесте. Нужны реальные числа из вашего опыта, а не округлённое «выдержали в три раза больше».
Сам расчёт удобно показать цепочкой:
- от бизнеса к RPS: 500 тысяч активных пользователей в день по 20 запросов это 10 млн запросов, делим на 86 400 секунд и получаем в среднем около 115 RPS. Пик в несколько раз выше среднего, считают по нему;
- от RPS к конкурентности: закон Литтла. При 400 RPS в пике и ответе за 150 мс в системе одновременно около 60 запросов;
- от конкурентности к воркерам: синхронный воркер Gunicorn обрабатывает один запрос за раз, значит нужно около 60 воркеров или асинхронный стек на Uvicorn. Стартовая рекомендация документации Gunicorn:
2 × CPU + 1воркеров на машину; - база: каждое соединение занимает слот, а у PostgreSQL по умолчанию
max_connections = 100. Отсюда пулы соединений и PgBouncer; - данные: строки в день, умноженные на размер строки и срок хранения.
Потом расчёт проверяют нагрузочным тестом: в Locust сценарии пишутся на Python, также подойдут k6 или JMeter. Смотрят не среднее, а p95 и p99 времени ответа.
Если проектировать с нуля не приходилось, так и скажите и проведите расчёт прямо на собеседовании на примере сервиса, над которым работали. Это честнее и убедительнее придуманной истории.
Где спотыкаются
Отвечают «выбрали микросервисы для масштабирования» без единой цифры. Архитектурное решение без расчёта звучит как мода, а не инженерия.
Считают по среднему трафику и забывают про пик и хвосты задержки. Именно они роняют сервис.
Масштабируют Python-воркеры, не посчитав базу. Двадцать подов по десять соединений упираются в лимит PostgreSQL раньше, чем в CPU.