Здравствуйте, Cyberax, Вы писали:

C>Но вот тут случается затыка — в VPC кончились свободные адреса и машины умирают сразу после запуска. Или в ASG у Амазаона что-то сломалось. Ну и может быть и просто нет свободной мощности и ASG выкидывает Insufficient Capacity Error.
Ага. И атомная бомба упала на датацентр. И абсолютно все решения надо делать с учетом этих маловероятных событий.

C>Существующие машины не способны справиться с потоком запросов, а frontend продолжает их слать. Отставание backend'а продолжает нарастать. Клиенты frontend'а паникуют, повторяя операции всё чаще. Отставание нарастает. Вскоре ни один клиент frontend'а не может получить результаты вовремя, пока backend обрабатывает уже заведомо ненужные сообщения.
Circuit breaker можно заимплементить по разному.

C>Как делать правильно? Очень просто: иметь небольшой оперативный запас в мощности и делать обработку так, что при повышении нагрузки время обработки плавно росло. При превышении нагрузки — активно делать load shedding, выдавая клиентам frontend'а ошибки.
Это не единствено возможный подход. Идентифицировать что бекенд не спрпвляется и начать рещать клиентов можно разнвми способами, выбор кокретного зависит от конкретных требований.


C>Ну то есть, проблема не решается нормально.

Еще раз. Единственный критерий нормальности решения проблемы — это соотвествия результаьа спецификации. Все. Точка.

C>Какая очередь может делать throttling отправляющей стороны? Это нельзя делать в SQS или ApacheMQ.
А не надо этого делать в предложенном мной подходе.

C>Примерно так и есть.
вопросов больше не имею