1

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 ?

santi
  • 651
  • 1
  • 6
  • 6

1 Answers1

1

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

Garry Taylor
  • 940
  • 8
  • 19
  • You described the advantages of event based approach, but if I understand correctly, the question was not about that. The question was about request-reply pattern using messaging - that specific case when first service sends request message to the second one and then blocks the thread and waits for a response message. How this approach is better than just doing an api call? – Taras Jan 05 '23 at 15:03
  • load balancing, Strong contracts, no DNS, private services (No public APIs). Easy A/B-Blue/Green deployments. Just a simple consumer, waiting to do its job :) – Garry Taylor Jan 06 '23 at 15:54