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

Question

Q1

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

Q2

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

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

Answer 1

Q1

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

Q2

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

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

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