Is REST best for micorservices architecture?

One of the first stages of application design is the choice of architecture. If the choice is for a microservices based architecture, the issue of inter-service communication is important. Often used is the REST API. Is this the best solution?

Synchronous character of REST

The main advantage of microservices based architecture with REST is the possibility of communication between microservices over HTTP, without the need for additional infrastructure. This is synchronous communication. Even if the response is sent with status code 202 (the request has been accepted for processing, but the processing has not been completed), the producer will be blocked until the server responds 202 decreasing throughputs.

As an example consider a system that is responsible for updating the inventory of shops network.

1. A stock update request is send to a REST gateway address.
2. The gateway forwards this request to the Warehouse Manager Service.
3. The Warehouse Manager updates the warewhouse stock based on the request it receives, and subsequently sends a request to the Stock Notification Service.
4. The Stock Notification Service sends a request to the Departments Manager Service, requesting all shops that have product in offer.
5. In the next step, Stock Notification Service sends a request to the Stock Manager for inventory update for each shop separately.
6. Each service then responds in turn, unwinding back to the API gateway.

Characteristics of REST

When analyzing this architecture, a couple of important flaws should be mentioned: blocking, single responsibility and coupling.

The synchronous character of REST will cause that the update stock operation will not return until the Stock Notification Service has completed its task of updating stocks of shops. If the product will be very popular, performance could potentially be affected and the scalability of the system will be difficult.

The knowledge that ‘when a product amount is updated, stocks of shops should be notified’ is ingrained into the Warehouse Manager Service but I think that this should not be the case. The responsibility of this service should be to update warehouse stock and nothing else. It should not need to know about the existence of the notification service at all. The two services are coupled in this model.

Due to the tightly coupled described system, there needs to be a failed strategy within the Warehouse Manager Service to deal with the scenario where the Stock Notification Service is not available. Should the warehouse update fail? Should the service retry?

Pipeline pattern

One of the ways to overcome the coupling of services is to follow the pipeline pattern. The architecture of our system could look like this:

Communication may be REST based but is no longer ‘point-to-point’. The pipeline entity is responsible for streamlining the data flows. With such an approach, the services must rely on the pipeline orchestrator, which is a third party entity, in order to function as a system, what is the disadvantage of this solution.

Messaging based system

Another alternative to REST in microservices architecture is the messaging-based system.
In this type of system, the input and output from services are defined as commands or events. Each service subscribes to the events and then receives these events reliably via a mechanism such as a messaging queue/broker when the events are placed in the queue by other services. The architecture of our system could be remodeled in this way:

Consistency is achieved through common knowledge of names and command/event format. This architecture has achieved a lot of flexibility, service isolation and autonomy. Warehouse Manager Service, for example, has a single responsibility, updates the warehouse stock. Its action is not related to other services that run after the job has been performed.

However, there are a few difficulties that arise when designing systems based on message queues. The programming model is generally more complex in an asynchronous system than a synchronous one, making it more difficult to design and implement. The fact that the result of the operation is not immediately returned may also increase the complexity of the system and user interface. It is difficult to analyze the flow of information in the system due to the spreading and autonomous nature of such microservices.

Read more: Key things you need to know about the architecture of applications

My answer to the asked question

Is REST best for microservices architecture? I tried to present pros and cons of different solutions. The answer to this question should be a result of the analysis of customer requirements because the answer is not always the same. In my opinion, in projects where synchronicity may be at least onerous, it is reasonable to use a messaging-based system.