Request based vs Event based architecture

Question

Q1

I know the fundamental different between event based vs request based/driven architecture. Question is if the Request-based always done in synchronously while the Event-based is always done in asynchronously ?

Q2

Also, in API world (request-response), you normally return 400 http code for if the request message is invalid. And fortunately, in API world we can perform contract testing making the integration to be more robust.

What would be the best way to handle this similar issue in the messaging queue other than putting the message in the error queue ? is it the responsibility of the pubsliher service or consumer service to get notified first of the problem ?

Mazurek

Answer 1

Q1

That's the fundamental difference. The event publisher doesn't care who consumes it. In req/response services are tied up.

Q2

In event driven system it's responsibility of publisher to include everything that other services can use. In case the event doesn't contain everything that it needs then you can't publish event at the first place so you need to make sure that's the case. This is whole point of event driven since consumer expects to pick the message with all the data it needs.

If you still are able to publish the event that wasn't well formatted then you would reject the event and definitely log it . If that rejected event was part of transaction and linked to publish of another event then you would raise the failed processing event (Saga Pattern).

The best practice is to raise event with all the necessary payload. If events are not well formatted then It's a bad design and will eventually get complicated to handle at large scale.

Douala

in theory is easy to say "bad design" but you cannot always cover all scenario. For example, ServiceA publishes transaction event which ServiceB consumes which expecting the Amount property to be greater than 0. But then one day the event includes "Refund" type transaction which Amount will be negative. In this case ServiceB will be throwing exception and putting it to error queue. Apart "bad team communication", what would you suggest to mitigate/prevent this sort of scenario ? – Mazurek

Microservices is an evolving approach where we improve the things as we go. Your refund example the other Service B can't make a contract change which is simply against open-closed principle and will have to be fixed eventually . But things can and do get bad. Since rejected messages are pushed to dead-letter queue so you are required to monitor your dead-letter queue and investigate the reason. You can trigger an alert based on rejected messages thresh hold. Monitoring is the key in general and specifically in this scenario. – Douala

nothing exceptional with your suggestion. of course i have implemented an alert for the dead letter q but then the debate now is who will be woken up in the middle of the night ? is it the team who writes ServiceA or ServiceB ? – Mazurek

"nothing exceptional with your suggestion. of course i have implemented" . I can't find that implementation part in your question ? Your question is generic so are the answers. if you don't like it you can always disagree respectfully . – Douala