Почему “несколько внешних запросов в онлайне” — плохой критический путь

Жёсткие требования по latency означают, что важна не средняя скорость, а предсказуемость. Внешние системы дают непредсказуемость по сети, нагрузке и очередям, поэтому они ухудшают p95/p99.

1) Суммирование задержек и рост хвостов

Если запрос идёт последовательно по 3 системам:

• общий latency ≈ сумма трёх вызовов + накладные расходы

Если параллельно:

• общий latency ≈ максимум из трёх вызовов (самый медленный определяет ответ)

В обоих случаях:

• чем больше внешних вызовов, тем выше шанс “длинного хвоста”

2) Рост вероятности ошибки

Определение: Failure amplification — когда стабильность всей операции падает из-за композиции нескольких зависимостей.

Пример рассуждения:

• если у каждой системы 99.5% успешных ответов,

• то у трёх зависимостей шанс успеха будет примерно 0.995³, то есть заметно ниже, чем у одной.

3) Лимиты и конкурентная нагрузка

Внешние системы часто имеют:

• rate limit / квоты

• ограничения на параллельность

• очереди под нагрузкой

Под высоким RPS вы можете сами создать зависимостям перегрузку.

4) Типичные замены “внешним запросам в моменте”

Чтобы снять зависимости с критического пути:

• кэширование результатов/частей результата

• локальная витрина данных (денормализованная таблица под чтение)

• асинхронное обновление через события/очереди

• предрасчёт по расписанию или по событию

5) Если всё-таки нужно ходить наружу

Тогда обязательно:

• строгие таймауты

• fallback (упрощённый ответ)

• circuit breaker

• лимит параллелизма, чтобы не устроить лавину

Вывод

Несколько внешних запросов на критическом пути ухудшают p95/p99 и надёжность из-за суммирования задержек и множества точек отказа. Для жёсткого SLA обычно выносят зависимые вычисления из запроса: кэш, витрины, асинхронные обновления.