Архитектура на основе запросов и событий

Question

Q1

Я знаю фундаментальные различия между архитектурой, основанной на событиях, и архитектурой, основанной на запросах.Вопрос в том, всегда ли основанный на запросе выполняется синхронно, а основанный на событиях всегда выполняется асинхронно?

Q2

Кроме того, в мире API (запрос-ответ) вы обычно возвращаете 400http код, если сообщение с запросом недействительно.И, к счастью, в мире API мы можем выполнить контрактное тестирование, что сделает интеграцию более надежной.

Как лучше всего справиться с подобной проблемой в очереди сообщений, кроме помещения сообщения в очередь ошибок?является ли обязанностью службы Pubsliher или службы поддержки пользователей получать уведомления в первую очередь о проблеме?

Answer 1

Q1

В этом принципиальная разница.Издателю события все равно, кто его потребляет.В запросе / ответе сервисы завязаны.

Q2

В системе, управляемой событиями, издатель несет ответственность за включение всего, что могут использовать другие службы.Если событие не содержит всего, что ему нужно, вы не можете опубликовать событие в первую очередь, поэтому вам нужно убедиться, что это так.В этом весь смысл события, поскольку потребитель ожидает выбрать сообщение со всеми необходимыми ему данными.

Если вы все еще можете опубликовать событие, которое не было должным образом отформатировано, вы отклоните событие и определенновойдитеЕсли это отклоненное событие было частью транзакции и связано с публикацией другого события, вы бы инициировали событие неудачной обработки (Saga Pattern).

Лучше всего вызывать событие со всей необходимой полезной нагрузкой.Если события плохо отформатированы, то это плохой дизайн, и со временем его будет сложно обрабатывать в больших масштабах.