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

C>>2) Простые best effort fire-and-forget пинги для внешних систем с уведомлениями об изменениях.
I>Ну я еще парочку накину:
I> — буферизирование пиковой нагрузки
ОЧЕНЬ плохая идея. Пиковую нагрузку надо или сразу обрабатывать, или кидать ошибки вызывающей системе, чтобы она замедлилась и не создавала такой нагрузки.

I> — интеграция разнородных систем
I> — обеспечение high availability + guaranteed delivery
Ещё хуже.

I>Но это далеко не полный список, уверяю тебя
Ну так плохих идей вообще очень много.

I>Пусть ломается, надо делать нормальный мониторинг, дизастер рекавери и нотификацию о факапе. А если к этому всему прикрутить ивент сорцинг в том или ином виде, то "проиграть" историю по всем сохраненным сообщениям после фикса факапа — плевое дело.
И как мониторинг позволит справится с backlog'ом сообщений, который ещё и будет расти во время диагностики причин ошибки? Особенно, если система построена на гарантированной доставке.

C>>У меня их терабайт в час на некоторых системах. Но речь не об этом, проблема в том, что если сообщение удалено, то во многих системах на сообщениях ничерта не понятно в каком состоянии стала находится система. Была ли сделана задача, связанная с сообщением?
I>Correlation id и поиск по логам. 2 минуты дела на таких обьемах, при условии использования нормального лог агрегатора.
Проблема в том, что если сообщения вызывают изменение чего-то, то при пропуске одного сообщения не очень понятно итоговое состояние.

C>>Если retry'ев много, то отравленные сообщения вытеснят все остальные, даже если скорость их поступления незначительная.
I>Тут все сильно зависит от контекста. Никто не мешает настроить число ретраев = 0, и вуаля, все сообщения обрабатываются один раз. А еще у сообщений есть волшебное свойство visibility timeout, которое сможет запостпонить ретрай на полчасика.
Оба варианта ведут к другим проблемам. Отсутствие retry делает обработку best-effort'ом в лучшем случае. Таймаут вызовет мину замедленного действия, позволив отравленным сообщениям постепенно накопиться и потом разом всё убить.

I>Как видишь достаточно гибко можно наконфигурить и подстроить под бизнес кейс.
Они не решают основную проблему — отсутствие "backpressure". Отправляющая сообщения сторона не знает, что backend может прямо сейчас находится при смерти, и что неплохо бы начинать делать throttling входящих запросов.

Кстати, эта проблема как раз может решаться ограничением максимальной глубины очереди.

C>>Ой, ну не надо. Производители могут дать SLA в 146%, только ведь всё равно всё упадёт.
I>Ну и пусть падает. Главное в контракте штрафные санкции правильно прописать. Тогда глядишь и производитель задумается, во что ему падение выйдет и какие то меры предпримет.
Производители себе не враги, и никакие серьёзные последствия для них не последуют.