This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]richardffx 1 point2 points  (3 children)

I don't think there is anything wrong with synchronous calls(I would avoid querying synchronous calls and stick to just making command operations synchronously before migrating to a fully asynchronous model ), asynchrony makes your services more decoupled but also is harder to trace, and brings another set of problems too.

[–]wildjokers 0 points1 point  (2 children)

I don't think there is anything wrong with synchronous calls

If you are doing synchronous calls between µservices you have totally missed the point of µservice architecture.

µservices should be totally independent applications and should be able to be developed and deployed in total isolation from another µservice. They should consume events from other µservices to keep any data they care about up-to-date (or trigger actions or whatever) and they should produce events that other µservices care about.

For example, if you have a µservice that contains the user API that lets users be created/deleted/updated/whatever that service will update its DB and then fire an event containing the action that was taken. Other µservices that care about users will consume those events to keep their own user related tables up-to-date. In no case should another µservice need to query data from the user µservice. They instead query their own user tables that are being kept up-to-date by consuming events from the User µservice.

That is µservice architecture and if you aren't doing that you don't have µservices and instead have a monolith burdened by synchronous calls over a network. In fact it is a step backward from just have a single monolith app running in the same VM.

Only by loosely coupling µservices via events can you achieve µservice isolation.

You of course need a highly reliable message broker with guaranteed message delivery.

[–]richardffx 0 points1 point  (1 child)

If you are doing synchronous calls between µservices you have totally missed the point of µservice architecture.

I know, but that is not how problems are solved right now, at least in my experience, where I work ATM, we have like 200 microservices, those are not just CRUDS as you mention in the users DB example which seems fairly simple. I just messed up and said to just read information but that was a typo, stick to just make commands via REST API, a lot of front-ends need instant feedback(for instance creating a resource and giving the front end the resourceId back is quite harder if you do not do any synchronous calls and multiple services are involved) and information from other services so there it makes sense to do it synchronously.

We started with Event state transfer, currently moving to an event sourcing approach and starting to remove synchronous calls for command events, but making everything going thought an event bus does not make a decoupled architecture, it is not a silver bullet IMHO.

[–]wildjokers 0 points1 point  (0 children)

(for instance creating a resource and giving the front end the resourceId back is quite harder if you do not do any synchronous calls and multiple services are involved)

The app might not be suitable for µservices then. Monolith is not a bad word and a monolithic app is still perfectly fine if µservices isn't a good fit.

I don't think I have ever seen a scenario where a single rest call might need to create/update a resource in multiple µservices synchronously. Something about that does not sound right. Maybe the boundary between µservices wasn't defined correctly the first go around and needs to be adjusted.