S>С одной стороны шина тут не очень чтобы очень, особенно учитывая не самый высокий уровень нагрузки, но с др. стороны
S>есть плюшки типа потери данных

Классика: разделение системы на части:
* "тупое хранилище" — простая и надежная часть
* "бизнес-логика" — нагромождение спагетти, падучее и нервное

Когда не уверен в том, что можешь сделать надежный сервис, приходится подстилать соломку в виде отдельного "хранилища запросов", будь то MQ или что-то еще в этом роде. Сложная система обычно уступает простой по надежности. Математика: 100 связанных компонентов, каждый из которых имеет 99% надежность, имеют общую надежность ~37%. И психология: наш мозг не умеет удалять, поэтому решает проблему слишком сложной системы дальнейшим увеличением сложности (добавлением еще одного компонента, message queue/bus). Метрика, за которой гонятся, как правило не включает требования к latency. Оттого и так популярны все эти "retry mechanisms".

S>С одной стороны шина тут не очень чтобы очень, особенно учитывая не самый высокий уровень нагрузки, но с др. стороны
S>есть плюшки типа потери данных

Классика: разделение системы на части:
* "тупое хранилище" — простая и надежная часть
* "бизнес-логика" — нагромождение спагетти, падучее и нервное

Когда не уверен в том, что можешь сделать надежный сервис, приходится подстилать соломку в виде отдельного "хранилища запросов", будь то MQ или что-то еще в этом роде. Сложная система обычно уступает простой по надежности. Математика: 100 связанных компонентов, каждый из которых имеет 99% надежность, имеют общую надежность ~37%. И психология: наш мозг не умеет удалять, поэтому решает проблему слишком сложной системы дальнейшим увеличением сложности (добавлением еще одного компонента, message queue/bus). Метрика, за которой гонятся, как правило не включает требования к latency. Оттого и так популярны все эти "retry mechanisms".