Is synchronous communication between services anti-pattern in microservices?

Question

I am somewhat new to microservices. I am currently developing an application using microservices and I am using both synchronous and asynchronous communication methods. Recently I saw few article saying that you shouldn't use synchronous(http) communication and should only use asynchronous(message broker).

So my first question is as the in title "Is synchronous communication between services anti-pattern in microservices ?"

And if it's yes, then how do I overcome this kinda situation: let's say I have two services called 'users' and 'messages' and user A wants to send a message to user B. so when user A sends a message I want to check user A has permission to send messages to user B, which permitions contains in user service. so order to get those information I have to do a request to user service from message service. How do I overcome this without using synchronous request to user service ?

Answer 1

You are right, synchronous interaction in microservice architecture is often called an antipattern, but I would not call it that, because we still often use this pattern.

Also, which pattern to use depends very much on your microservice architecture of the entire system as a whole.

You can use synchronous communication between services where it is really necessary and justified. I would use asynchronous communication wherever an instant response from another service is not required. Ideally, you should minimize synchronous interactions, but unfortunately, you still can't do without them, because there are situations when the client needs an instant response from the services.

The most popular synchronous communication technologies are:

• REST
• gRPC

I would recommend reading the pattern of synchronous interaction between services in the microservice architecture at the following link.

Answer 2

First of all, every decision in software architecture is a trade-off, as mentioned in the book: Software Architecture Fundamentals (Richards and Ford). So, the term anti-pattern I'm not sure is the right term for your question.

On the other hand, it is true that there are too many articles and books that are not really clear about this. My interpretation is that in order to have independent deployment (a strong design decision on the MS style), there cannot be sync communication between microservices. If you have sync communication between "users" and "messages", then, one depends on the other to be running/alive, which won't allow you to have independent deployment (then you have what now is called distributed monolith).

So, to fix this, if you decide that the data that expresses which user can send messages to others belongs on the "users'' microservice, that data must be duplicated in the "messages" microservice (duplicating just the minimum necessary to perform the task you need. And this duplication occurs using a pub/sub mechanism). With this, both services are self-contained, their local database has the necessary data to perform the task. If that is too much complexity, then, maybe you should aggregate those services into a single one.

I believe the big problem is about the term "micro". The cite below is from the book Continuous Architecture in Practice (Murat Erder and others).

"As a side note on microservices, we want to emphasize that the overall objective is to define loosely coupled components that can evolve independently (principle 4, Architect for change—leverage the “power of small”). However, micro can be interpreted as a desire to have components with an extremely small scope, which can result in unnecessary complexity of managing dependencies and interaction patterns. In addition, it can cause performance issues. As mentioned in Chapter 6, “Performance as an Architectural Concern,” calls between too many microservice instances can be costly in terms of overall execution time. The decision on the scope of microservices should be driven by your context and problem domain. Think about functions (or features) that will evolve together. The goal is to have loosely coupled, internally cohesive components rather than arbitrarily small services for their own sake."

Hope that helps.