Какой стек технологий и фреймворков используется для написания сервисов на Python?
Что проверяют
Знаете ли вы современную экосистему Python для бэкенда и умеете ли подобрать инструменты под задачу, а не перечислить всё известное. Обычно следом спрашивают, чем FastAPI отличается от Django и когда вы выберете одно вместо другого.
Как отвечать
Идите по слоям сервиса и у каждого называйте основной вариант с причиной:
- веб-фреймворк: Django с DRF для продукта с админкой, ORM и множеством CRUD-сущностей; FastAPI для API-сервисов с асинхронным вводом-выводом, валидацией через Pydantic и автогенерацией OpenAPI. Flask в новых проектах встречается реже, Tornado почти только в легаси;
- сервер приложений: ASGI через Uvicorn (часто под Gunicorn с воркерами Uvicorn), для Django по-прежнему встречается WSGI;
- работа с БД: PostgreSQL, SQLAlchemy 2.0 (в том числе асинхронный режим с
asyncpg), миграции Alembic; в Django своя ORM и свои миграции; - фон и очереди: Celery с Redis или RabbitMQ, для асинхронного кода Taskiq или arq, для потоков событий Kafka;
- инструменты:
uvили Poetry для зависимостей, Ruff как линтер и форматтер, mypy или pyright для типов, pytest с фикстурами и Testcontainers для интеграционных тестов; - эксплуатация: Docker, Kubernetes, метрики Prometheus, трейсинг OpenTelemetry, ошибки в Sentry, структурированные логи.
Хорошо назвать версию Python: в новых сервисах это 3.12 и новее. И обязательно покажите связку на примере: «сервис заказов на FastAPI и SQLAlchemy, события в Kafka, фоновые пересчёты в Celery».
Где спотыкаются
Выдают список из двадцати технологий без контекста. Интервьюеру важнее, почему в конкретном сервисе выбран именно этот набор.
Считают, что асинхронность сама всё ускоряет. Блокирующий вызов вроде requests.get или синхронного драйвера внутри async def останавливает весь event loop, и сервис работает хуже синхронного.
Не видят границу между вводом-выводом и вычислениями. Тяжёлую CPU-работу не ускорит ни asyncio, ни больше корутин, её выносят в отдельные процессы или воркеры Celery.