Deadline propagation
Бывали ли в вашей практике каскадные сбои? У меня — да 🥲 Такое может происходить, когда, например, таймаут запроса уже истёк, а внутренние сервисы продолжают его обрабатывать. Система начинает деградировать: ответы замедляются, клиенты усиливают нагрузку за счёт ретраев, а перезапуск инстансов только усугубляет ситуацию — поток запросов устремляется в ещё живые экземпляры. В итоге — коллапс, который часто лечится полной остановкой трафика и перезапуском всей системы 🔪
Одно из простых и очень эффективных решений — deadline propagation. Задали таймаут один раз — и он идёт по всей цепочке вызовов. Всё, что не укладывается во время — просто не выполняется. Меньше лишней нагрузки, больше стабильности и спокойствия.
Если вы ещё не используете этот паттерн — рекомендую посмотреть, как он реализован в userver от Яндекса: https://userver.tech/d6/d64/md_en_2userver_2deadline__propagation.html
· 30.06.2025
А что , если все цепочки не укладываются ? Я вот думаю , что можно было бы Circuit Breaker заюзать, его предоставляет большое количество гейтвеев , тогда можно не так агрессивно деградировать систему , как при ее полном перезапуске
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
коммент удалён
· 30.06.2025
Circuit breaker поможет, но уже тогда, когда система начала деградировать. Если таймауты слишком длинные, то сервис копит в себе кучу запросов, которые клиентам уже давно не нужны. В таком случае ограничить трафик будет норм стратегией. Но при этом производительность сервиса низкая, т.к. он будет занят обработкой зависших запросов. Вот тут как раз короткие таймауты помогут не тратить ресурсы сервиса на мертвые запросы, мы просто их отбрасываем.
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
ответ удалён