В каких ситуациях проблема производительности связана не с фреймворком, а с архитектурой приложения?

Правильный диагноз начинается с понимания, где реально тратится время: в CPU, в I/O, в очередях или во внешних зависимостях.

Определение

Архитектурная проблема производительности — это ограничение, вызванное структурой компонентов и их взаимодействиями (данные, зависимости, последовательность шагов), а не конкретной веб-обвязкой.

Признаки, что “виноват” не фреймворк

Ниже — типовые случаи, когда миграция на другой фреймворк почти не меняет картину:

1. Последовательные внешние вызовы

   • сервис делает 5–10 HTTP-запросов по цепочке

   • общий latency ≈ сумма ожиданий

2. N+1 и плохие запросы к БД

   • много мелких запросов вместо одного батча/джойна

   • отсутствие индексов, тяжёлые сортировки/фильтры

3. Неправильная модель данных

   • чтение “широких” сущностей, лишние поля/джойны

   • нет денормализации там, где она оправдана

4. Отсутствие кеша или неверный кеш

   • одинаковые запросы постоянно пересчитываются

   • TTL не соответствует бизнес-реальности

5. Тяжёлые операции в request-path

   • генерация отчётов, большие сериализации, компрессия

   • операции, которые лучше вынести в фон

6. Неуправляемые ретраи и каскадные отказы

   • при сбое зависимости система начинает “долбить” её сильнее

7. Ограничения внешних сервисов

   • rate limits, квоты, платные лимиты, долгие ответы

Как подтвердить, что это архитектура (а не фреймворк)

Сначала нужно одно связное предложение: подтверждение делается измерениями, а не догадками.

1. Трассировка (distributed tracing)

   • видно, сколько времени ушло на БД/HTTP/очереди

2. Метрики

   • p95/p99 latency, saturation воркеров, pool connections, error rate

3. Профилирование

   • если CPU низкий, а latency высокий — вероятно I/O/очереди/зависимости

Мини-пример: архитектурный “бутылочный горлышко”

def handler():
    user = db.get_user(user_id)
    # N+1: для каждого элемента — отдельный запрос
    items = [db.get_item(i) for i in user.item_ids]
    return items

Здесь смена фреймворка не устранит N+1 — нужен батч/запрос другим способом.

Что обычно меняют архитектурно

1. Параллелизм внешних вызовов + лимитирование

2. Кеширование (Redis, in-process, CDN — по контексту)

3. Асинхронные пайплайны (очереди, фоновые воркеры)

4. Оптимизация запросов/индексов и пересмотр модели данных

5. Circuit breaker / backpressure для защиты от каскадов

Вывод

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