Почему подход с запросами к нескольким внешним системам в момент обработки пользовательского запроса может не подходить для систем с жёсткими требованиями к latency?

Question

Каждый внешний вызов добавляет задержку и разброс времени ответа, а при нескольких вызовах хвостовая задержка растёт ещё сильнее. Кроме latency вы увеличиваете риск ошибки: если одна из систем недоступна, падает весь пользовательский запрос. Параллелизация помогает, но всё равно упирается в самый медленный вызов и сетевые проблемы. В системах со строгим SLA обычно делают предрасчёт, кэш, локальные витрины или асинхронные обновления, чтобы не зависеть от внешних систем “на горячем пути”.

YeaHub · Accepted Answer

Почему “несколько внешних запросов в онлайне” — плохой критический путьЖёсткие требования по 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 обычно выносят зависимые вычисления из запроса: кэш, витрины, асинхронные обновления.