CODEWITHSUNDEEP
restarchitecturemicroservicesdistributed-system
curiosityrock
curiosityrock

Reputation: 213

Rest api vs event-based communication

I'm curious about using sync or async(event based or pub/sub) approach in my microservice.

i have a python backend service that was written in rest and almost all my endpoints have one small dependency to make request to another microservice.

service 1 -> makes rest api get request -> service 2 (returns some data)

service uses that data as a filter and makes a request to its corresponding database, then return data to the client.

in my case, i think using async communication is not an option... since i need this data immediately before i send a request to db and send it back to the user. That's why i am using rest to communicate with my second service. However, i was reading some articles and it seems like people suggest using async or event based communication for similar use cases. I was always under the impression that event based or async approach might be more ideal if I have a request that i can fire and forget about it..(more like a background process) Just wanted to ask if it's a good place for me to explore event based more for my particular use case or i should stick with rest?

Note:it was recommended as an ideal solution in the book( Microservices by Sam Newman). These two services who need response from each other and cannot just fire these requests and forget about it are using event based or async approach- i guess kind of similar to my case

enter image description here

Upvotes: 0

Views: 999

Answers (1)

Maxim Fateev
Maxim Fateev

Reputation: 6880

It is not about sync vs async. It is about resiliency.

You need queues or some other form of persistence if you need to ensure that the request is not going to be lost in case of process crashes and other types of failures. In the diagram, you included it is not OK to lose reservations.

Think about your use case. Is it OK to lose the request if service one crashes while service 2 processes it? If it is OK and the request can be retried by the caller then stick with your current design.

Upvotes: 0

Related Questions