Почему ваши API медленно отвечают: скрытые bottlenecks, о которых молчат мониторинги

Вы смотрите в APM: CPU 20%, память 40%, сеть в норме. Но ответ от `/api/reports` приходит за 12 секунд. Где искать проблему, когда метрики врут? Топ-3 неочевидных тормоза: 1. N+1 запросы в ORM Фреймворк лениво подтягивает связанные модели. На экране вы видите 1 строку, под капотом — 100 запросов к БД. Решение: `select_related` / `prefetch_related`, профилирование через `django-debug-toolbar` или `EXPLAIN ANALYZE`. 2. Синхронные внешние вызовы Ваш сервис ждёт ответ от платёжки, почтового шлюза или внутреннего микросервиса. Таймаут 5 секунд × 3 сервиса = 15 секунд ожидания. Решение: асинхронные очереди (Celery/RQ), circuit breaker паттерн, кеширование ответов с TTL. 3. Сериализация «тяжёлых» объектов Превращение ORM-моделей в JSON, маппинг в DTO, валидация полей. На 1000 записей это добавляет 200-500 мс незаметно для CPU-метрики. Решение: пагинация, частичные ответы (`fields=...`), готовые сериализаторы вместо ручных `dict()` циклов. Как диагностировать быстро: — Включите slow query log на БД (>100 мс) — Добавьте кастомные метрики на каждый внешний вызов — Логируйте время между «запрос получен» и «ответ отдан» на уровне middleware — Используйте distributed tracing (OpenTelemetry, Jaeger) для микросервисов Чек-лист оптимизации: ✅ Индексы по полям фильтрации и сортировки ✅ Пагинация по умолчанию (даже для внутренних API) ✅ Кеширование на уровне запроса, если данные не меняются часто ✅ Таймауты и ретраи с экспоненциальной задержкой ✅ Регулярный `VACUUM` и анализ статистики (для PostgreSQL) «Быстрый API — это не про железо. Это про уважение к времени пользователя и дисциплину в архитектуре».