Был ли опыт работы с высоконагруженными проектами

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

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

Как отвечать

Стройте ответ на своём проекте, по шагам:

• масштаб: запросы в секунду в пике, объём данных, число экземпляров сервиса. Нагрузка относительна, поэтому нужны цифры, а не эпитет;
• метрики: латентность по перцентилям p95 и p99, а не по среднему; Prometheus и Grafana, APM, трейсинг через OpenTelemetry;
• поиск узкого места: профилировщики py-spy и cProfile, EXPLAIN ANALYZE для медленных запросов. Чаще всего тормозит не Python, а запросы N+1, отсутствующий индекс или исчерпанный пул соединений;
• что сделали: кеш в Redis с продуманной инвалидацией, пул соединений или PgBouncer, вынос тяжёлого в фоновые задачи через Celery или очередь, асинхронный стек (FastAPI, asyncio) для I/O, горизонтальное масштабирование;
• результат: было и стало в тех же метриках, и ваша личная роль отдельно от роли команды.

Покажите понимание GIL: в стандартной сборке CPython потоки не ускоряют вычисления. CPU-bound работу выносят в процессы (multiprocessing, несколько воркеров Gunicorn или Uvicorn) или в нативный код, а asyncio помогает только там, где сервис ждёт I/O.

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

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

Называют высокой нагрузкой пару сотен пользователей в день, а на вопрос про RPS и перцентили ответить нечем.

Приносят круглые проценты вроде «ускорили на 40%», но не могут сказать, что именно мерили и в каких условиях.

Лечат всё потоками или переписыванием на asyncio, не замечая, что синхронный драйвер базы или тяжёлое вычисление внутри корутины блокирует весь event loop.