Замедление p99 latency в микросервисах часто рождается не из падений, а из «тормозов», которые все же отрабатывают до конца. InfoQ разбирает подход, где хеджированные запросы в бенчмарке сократили p99 на 74%: для команд, которые уже устали смотреть на зеленые дашборды и красный хвост задержек, это куда полезнее очередного совета «добавьте ретраи».
Речь идет о статье Prathamesh Bhope, опубликованной 28 мая 2026 года. Автор описывает адаптивный механизм hedging для fan-out архитектур, где один пользовательский запрос дергает десятки или сотни внутренних сервисов. Ключевой тезис простой и неприятный: если у каждого downstream-сервиса лишь 1% медленных ответов, на уровне всей системы это уже не косметика. При десяти вызовах вероятность поймать хотя бы один straggler доходит примерно до 9,6%, а при ста вызовах — до 63%. То есть задержку формирует не один «плохой» сервис, а накопление редких замедлений по всей цепочке.
В этом и состоит главный выпад статьи против привычных retry-механик. Ретрай помогает, когда запрос не завершился вовсе. Но straggler — это не отказ, а запрос, который завершится, просто заметно позже нормы. Если клиент в этот момент запускает повтор, он не лечит проблему, а добавляет второй запрос в уже напряженный бэкенд. В результате одна и та же логическая операция начинает занимать два слота вместо одного, и хвост задержек легко становится еще хуже. Хеджированные запросы работают иначе: клиент не ждет явного провала, а отправляет резервный запрос, пока основной еще висит, и берет тот ответ, который пришел первым. Проигравший отменяется.
Сама идея не новая: Bhope опирается на классическую работу Google The Tail at Scale Джеффри Дина и Луиса Баррозу, вышедшую в 2013 году. Новизна здесь в том, как убрать ручную настройку, которая обычно и ломает hedging в проде. Статический порог вроде «дублировать все, что дольше 50 мс» хорошо выглядит в лаборатории, но в реальной системе задержки плавают из-за нагрузки, деплоев, пауз GC и даже времени суток. Ночью такой порог может быть слишком агрессивным и плодить лишний трафик, а в пик — слишком консервативным и пропускать реальные straggler-случаи. Автор называет это типичной ловушкой: нужно заранее знать правильный ответ, чтобы правильно настроить систему, а в живой инфраструктуре этот ответ постоянно уезжает.
Для адаптации к реальному трафику в статье используется DDSketch — структура данных для приблизительной оценки квантилей в реальном времени. Ее плюс в том, что она дает оценку с постоянным потреблением памяти и временем обновления O(1), а относительная ошибка держится в пределах плюс-минус 1%. По данным автора, накладные расходы составляют около 35 наносекунд на запрос, что выглядит приемлемо даже для нагруженного клиента. Чтобы не залипать на старой статистике, механизм хранит измерения в скользящих окнах с ротацией: так порог для hedge-запроса строится не по «средней температуре за неделю», а по свежему поведению конкретного хоста. Идея здравая: латентность в микросервисах портится быстро, а вот ручная конфигурация почти всегда отстает.
Вторая проблема куда опаснее: если все запросы внезапно стали медленными из-за реальной аварии, агрессивное hedging способно удвоить нагрузку именно в тот момент, когда системе и так плохо. Здесь автор добавляет token bucket budget, который ограничивает долю резервных запросов от общего трафика. В статье в качестве примера фигурирует бюджет 10%: скорость пополнения bucket рассчитывается из текущего RPS и разрешенной доли hedge-трафика. В нормальном режиме, когда straggler-ов немного, этого хватает, чтобы «обгонять» хвостовые задержки. В аварийном режиме запас быстро выгорает, массовое дублирование прекращается, и сервис деградирует без саморазрушения. Для практиков это, пожалуй, важнее самой идеи hedging: красивый алгоритм без предохранителя в проде обычно заканчивается некрасиво.
Результаты пока получены не на боевой системе, а в воспроизводимой симуляции. Автор прогнал 50 тысяч запросов по модели бэкенда с логнормальным базовым распределением задержек и 5% вероятностью straggler-события — параметры, которые он считает близкими к реальному поведению микросервисов под умеренной нагрузкой. Исходники оформлены как open source Go-библиотека, а сам бенчмарк можно прогнать локально и подставить свои числа. Это важная оговорка: статья не обещает универсальные «минус 74%» для любого продакшна. Но она аккуратно показывает, что проблема p99 часто сидит не в отказах как таковых и не в «медленном сервисе номер семь», а в математике fan-out архитектуры, где редкие задержки складываются в системный хвост.
Для русскоязычных команд здесь есть вполне прикладной вывод. Если в вашей архитектуре много внутренних вызовов, а дашборды по каждому сервису выглядят прилично, это еще не значит, что пользовательский SLA в порядке. p50 и даже p90 легко маскируют историю, в которой основные деньги и нервы съедает именно p99. Хеджированные запросы в таком контексте выглядят не как серебряная пуля, а как инженерный инструмент с четкой областью применения: они полезны там, где основную боль создают straggler-ы, а не массовые отказы, и где команда готова дисциплинированно следить за бюджетом дополнительной нагрузки.
Следующий логичный вопрос — сколько команд дойдут до реального внедрения, а не остановятся на красивом графике из симуляции. Но сам вектор уже понятен: борьба за хвост задержек смещается от ручных таймаутов и ретраев к более адаптивной клиентской логике, которая умеет различать «медленно» и «сломалось». Разработчикам, которые хотят проверить механику на своих параметрах, пригодятся и статья, и связанные с ней артефакты: paper, описание DDSketch и Go-реализация собраны в материале .