Предохранитель
6 вызывающих обращаются к упавшей зависимости, которой нужно около 80мс, чтобы сообщить об этом. Одно плечо спрашивает каждый раз; другое прекращает после третьего отказа.
Velocity
Устранение задержек как архитектура, а не набор приёмов: оптимистичные мутации, уровни кэша, защита от лавины запросов, отложенный хвост — каждое измерено против наивной версии.
Что удерживает быстрый путь быстрым, когда зависимость таковой не является. Те же два плеча, те же настоящие модули — только теперь сломана, замедлена или зависла сама зависимость.
Параллельно — страница про водопады не должна его создавать.
Переборка
8 вызовов к зависимости в ~100мс уже удерживают пул из 4 мест, когда приходит один быстрый вызов. Одно плечо делит пул; другое даёт каждой возможности свой отсек.
Передача дедлайна
3 последовательных вызова к зависимости, которая никогда не отвечает вовремя. Одно плечо даёт каждому свой таймаут в 100мс; другое делит между ними единый бюджет в 150мс.
Сброс нагрузки и ограниченные повторы относятся к той же политике, но панели здесь не имеют: ни один из них не даёт сравнения, которое секундомер мог бы показать честно, а слабая демонстрация хуже её отсутствия. Оба покрыты юнит-тестами и документацией.
Думаете, этот паттерн можно сделать лучше? Расскажите как.
Оставить отзыв