Какие технические задачи связаны с масштабируемостью и надежностью

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

Понимаете ли вы, что масштабируемость и надёжность это разные свойства, и знаете ли конкретные приёмы для Python-сервиса. Следом обычно спрашивают, что в вашем приложении мешает запустить его в десяти экземплярах.

Как отвечать

Разведите понятия. Масштабируемость: система выдерживает рост нагрузки добавлением ресурсов. Надёжность: продолжает работать при сбоях частей.

Задачи масштабирования:

• stateless-приложение: сессии и кэш в Redis, файлы в объектном хранилище, тогда экземпляры можно множить за балансировщиком;
• конкурентность: из-за GIL потоки не параллелят CPU, поэтому процессы через gunicorn или uvicorn с воркерами, asyncio для I/O, тяжёлые вычисления в отдельные процессы;
• фоновые задачи: Celery с брокером, чтобы долгие операции не держали запрос;
• база: индексы, борьба с N+1 в Django ORM через select_related и prefetch_related, пул соединений через PgBouncer, реплики на чтение;
• кэш и автомасштабирование: Redis перед базой, HPA в Kubernetes.

Задачи надёжности:

• таймауты на все внешние вызовы: у requests таймаута по умолчанию нет, запрос может висеть бесконечно;
• повторы с экспоненциальной задержкой и джиттером (tenacity) плюс идемпотентность, чтобы повтор не списал деньги дважды;
• circuit breaker, health checks, graceful shutdown;
• наблюдаемость: метрики в Prometheus и Grafana, ошибки в Sentry, SLO и алерты на них.

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

Отвечают «добавим серверов», хотя сессии лежат в памяти процесса, а загрузки на локальном диске. Второй экземпляр сразу ломает логику.

Включают повторы без таймаутов и идемпотентности. При сбое зависимости это превращается в лавину запросов, которая добивает её окончательно.

Смешивают понятия и не называют метрик. Утверждение «стало надёжнее» без доступности, p99 или числа инцидентов ничего не доказывает.