Оправдано ли применение очередей сообщений и архитектуре с событийной моделью?

Question

[Lavlet]

Есть сервис, который принимает запросы по REST на какие-то выборки данных. Изменение и добавление данных также проводится через него. Необходимо уведомлять сервисы, которые подпишутся на это, об изменении данных.
Думал об архитектуре Сервис данных -> Диспетчер подписок (принимает собтие и распределяет сообщения по очередям, также хранит кто подписался на какое-либо событие) -> Очереди сообщений -> Подписчики.

Как думаете, насколько оправдана ли такая архитектура? Может быть есть какой-то известный паттерн проектирования, который не увидел, что описывает подобную задачу?

Answer 1

[ApeCoder]

Описано в книжке Фаулера, например

https://www.enterpriseintegrationpatterns.com/patt...

Answer 2

[Александр Юдаков]

Регулярно использую похожую конструкцию. Пара моментов:
1. Никогда не использую внешние универсальные очереди сообщений (MSMQ etc). Вместо этого - легкое простое специализированное решение для каждого конкретного случая.
2. Всегда интегрирую в единое целое то, что вы называете "сервис данных", "диспетчер подписок" и "очереди сообщений".