CODEWITHSUNDEEP
microservicesmessage-queuemasstransit
santi
santi

Reputation: 661

The purpose of MassTransit request/response

I'm just getting started to implement the event messages in the microservices with MassTransit. The message publish makes a lot of sense to me that beneficial to the responsiveness of the microservice. However the request and response does seems comparable with the API synchronous call that the response has to return in order to complete the entire procedural logics. I just don't get the idea why and when should I implement this pattern ? Isn't that API call is much more simpler than place the request in a queue and wait until it was processed only then get the response ?

Upvotes: 2

Views: 1092

Answers (3)

adisco
adisco

Reputation: 17

There are little differences between traditional http API call and mass transit request/response pattern, also they are similar:

  • In both, the client are blocked
  • http call is simple and performant
  • mass transit req/resp gives you less coupling, but there is little overhead in terms of performance

So, if you are already using mass transit in your environment, if you call will be less than 30secs, you can benefit from less coupling of MTransit.If not, you can take full advantage of other publish, subscribe pattern of Transit to make your implementation scaleable .

If you don't have messages queue infrastructure already in your environment, and your microservices are simple short call with little needs for scaling in future, stay with traditional http API call. It will make your life simple. Watch below for further information:

https://youtu.be/NjsoykEOkrk?si=GtD2B_sHIul6mcK6

Upvotes: 0

santi
santi

Reputation: 661

The difference that makes a clear distinction to me is the request/response somehow ignore the need of authentication/authorization when the sender try to access the other microservice

Upvotes: 0

Garry Taylor
Garry Taylor

Reputation: 1115

Massive questions here!

Isn't that API call is much more simpler than place the request in a queue and wait until it was processed only then get the response

Simple terms, no. What if this was a customer completing an order, and there was a network timeout, database lock or some other common event. The order is lost.

What about setting up DNS, Load Balancers, multiple instances of the API, Swagger Docs, Validation, Good Error responses and then Monitoring. Datadog, APM and logging. See you in a few months :)

Create a consumer, start it, ensure 100% delivery and process in a few hours not months.

Building in load balancing, service discovery, retry and error logging. Not to mention amazing operability with APM tracing.

request and response does seems comparable with the API

It's not.. it better but a completely different way of looking at the problem. You have to think in terms of Events. What happens, what data changes and what I need to care about.

look into Event Driven Architecture and choreography, orchestration and Sagas.

This can't be explained within a Stack Overflow post... you have to change your mindset a little.

But in simple terms, a traditional API completes a process, Say buying a PS5. When the API call finishes the order is complete. This can take 5 - 30 seconds. during this time the server is locked up, a tread is locked, the customer is waiting and the changes of something going wrong is high.

If you raise events, the process completes instantly. The customer is returns to a holding page and the server is free to process other orders.

When a Consumer processes the order, an event is raised and the customer can see the order was successful.

It's also possible to return data from an Event. however, I have found, keeping the data minimal is best. Allow the API to raise events, consumers to process them and something like Sockets/SignalR/Blazor to communicate with the customer/ui.

I have a video on Saga's that you might find useful. I think this will help you understand how data can move between events.

https://youtu.be/Vwfngk0YhLs

Upvotes: 2

Related Questions