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

I>...

Меня очень заинтересовала эта ветка обсуждения, жаль, что до конструктива не добрались.

Пока суммируя недостатки озвученные выше вижу следующее — если еще осталось желание поправьте меня:
* Системы на сообщениях будут иметь меньшую availability из-за потерь сообщений, это можно отмести для систем, где availability самой message queue system вполне достаточна для бизнеса.
* С точки зрения сопровождения восстановление состояния системы при ошибке будет более сложным -- насколько я вижу correlation id / request id частично решает вопрос, но в случае потерь сообщений это становится сложным.
* Сложная обработка случаев типа multicast storm. Необходимо в архитектуру закладывать способ работы со сценарием когда система позволяет накопить больше сообщений, чем может обработать.
* Непонятен общий рецепт cirquit breaker'a для сценариев когда компонент принимающий сообщение отваливается с ошибкой и накапливаются retries (частично решается для ряда бизнес кейсов установкой visibility timeouts в большое значение или retry==0 когда можно считать что клиент просто каким-то образом поймет инициирует retry) либо ограничением на максимальную глубину очереди (как тогда обрабатывать клиентские запросы? получается что-то некрасивое когда клик по кнопке сразу приводит к ошибке из-за невозможности инициировать обработку). Установка retry==0 позволяет гарантировать лишь best effort обработку, большой visibility timeout создает угрозу перенасыщения сообщениями (см пункт выше).

Да, и отвечая на вопрос выше про альтернативы асинхронным сообщениям для критических сервисов используют workflow / orchestration engines типа Amazon SWF или Uber Cadence — последний уберовцы построили уже имея внутреннюю "durable and scalable" message queue system — cherami.

Пока вроде бы очевидна неприменимость message queue-based систем для построения систем требующих максимальной надежности типа обработки заказов от пользователя, которые часто строят на подобии orchestration engines и мне кажется тут у вас консенсус —

Cyberax:

Пока я для себя нашёл два нормальных применения очередей:
1) Раскидывание вычислений или длинных асинхронных задач по вычислительному кластеру.
2) Простые best effort fire-and-forget пинги для внешних систем с уведомлениями об изменениях.

itslave:

в спецификациях вполне может быть написано: "потеря до Х% данных допустима". Пример — влегкую, допустим у тебя сайт flightradar24, который прямо в риал тайме слушает местоположжение самолетов(они могут бродкастить каждую секунду) и рисует это на веб странце.

Видимо, все же с точки зрения применимости речь идет об одних и тех же сценариях — плюс может быть таких, где в отличие от Амазона не требуется >99.99% availability и хватит даже 99% -- суммарная недоступность сайта <4 дня в год вполне может быть приемлема для задач многих небольших компаний, если не брать в расчет области типа medicine и digital commerce.

И кстати, было бы интересно узнать — какой бизнес сценарий был решен на очередях?