Одним из решенеим является - Перейти от паттерна оркестрация к паттерну хареографии ( public - subscribe)
И немного об антипатернах
-
Прием неограниченного кол-ва запросов
Лучше быстро выйти из строя, чем долго зависать на выполнение запросов . Для этого можно применить стратегию rate limiting в load balancer or proxy, что позволит так же избежать DDoы-атак. Если число запросов, ожидающих очередь, превыющий допустимого передела возможности сервера, то они подлежат отклонению.
Или сброс трафика, путем ответа HTTP 503 ( Service unavailable)
-
Повторные попытки от клиента
Увеличить время на вызов последующео запроса ( jitter)
-
Сбой при неверном ввводе
Валидация данных, используя fuzz test (нечетких тестов )
-
Обработка отказа на основе близости
Перенаправлять трафиик, тольк на менее нагруженный кластеры
-
Сбой часто вызваны дополнительной обработкой
К примеру репликацией, нужна задержка или ограничение объема репликации
-
Длительное время запуска
Суть - не прогретый кеш, запросы идующие напрамяую к серверу, вызывающий сбой в системе при большой нагрузки . Следует отвадавть пердпочтение системам с более быстрым временм запуска.
by https://blog.mi.hdm-stuttgart.de/index.php/2022/03/03/cascading-failures-in-large-scale-distributed-systems/