@Lavlet

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

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

Как думаете, насколько оправдана ли такая архитектура? Может быть есть какой-то известный паттерн проектирования, который не увидел, что описывает подобную задачу?
  • Вопрос задан
  • 93 просмотра
Пригласить эксперта
Ответы на вопрос 2
AlexanderYudakov
@AlexanderYudakov
C#, 1С, Android, TypeScript
Регулярно использую похожую конструкцию. Пара моментов:
1. Никогда не использую внешние универсальные очереди сообщений (MSMQ etc). Вместо этого - легкое простое специализированное решение для каждого конкретного случая.
2. Всегда интегрирую в единое целое то, что вы называете "сервис данных", "диспетчер подписок" и "очереди сообщений".
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы
Hunt4You Севастополь
от 60 000 до 120 000 руб.
Fastdev AB Ижевск
До 140 000 руб.
23 марта 2019, в 16:34
700 руб./за проект
23 марта 2019, в 15:42
400 руб./в час