@Lavlet

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

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

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

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

Войти через TM ID
Похожие вопросы
Social Discovery Ventures Москва
До 250 000 руб.
LC Group Новосибирск
от 90 000 до 160 000 руб.
Hunt4You Севастополь
от 60 000 до 120 000 руб.