Rest API vs AMQP

Question

When is it better or more reasonable to communicate between internal Microservices using Rest API rather then AMQP?

I know that using Rest API the services will be more depanded each other so, can we say we should always avoid that and use AMQP?

Answer 1

When is it better or more reasonable to communicate between internal Microservices using Rest API rather then AMQP?

This heavily depends on your business/domain operations and what you need. It is true that for the majority of the cases most of the communication(or in most use cases) between 2 micro-services will be done over an queue. There are cases when a direct call through Rest API is needed or a better choice. This depends on your business requirement. I think if you want to achieve the best results you should use both approaches depending on the situation. For example lets say you have an online shop application and you have 4 micro-services:

• product-micro-service
• products-inventory-micro-service
• payment-micro-service
• orders-micro-service

Using Direct calls over Rest API

For example lets say that you want to finalize your order and add a payment method with which you will pay for the product which is in your shopping cart. Lets say for example that you are paying with a Credit Card. If your business logic says that the Credit Card must be valid before you close the order you need to call the payment-micro-service from the order-micro-service. This call will be in a synchronous way with a direct call over an Rest API which will wait for the response. In this case you need to wait for the response as your further logic depends on the fact that your Credit Card(payment method) is valid or not.

In this case publishing an event order-micro-service and listening to that event in payment-micro-service will create more delays, more complex event handling logic and rollback scenarios. Someone could ask a question:

What if the payment-micro-service is down or not reachable?

It does not matter if you use a direct call or an more complex operation over a queue. You can not continue/finalize your operation without the payment-micro-services. In that case you would probably return a Internal Server error or similar and ask the customer to retry the operation. Sometimes coupling between some micro-services is higher then between some others. This depends on the design of your micro-service architecture and the complexity of the operations.

Using queue

Most of the time communication cases between micro-services can be done over an queue. Typical example is if you create a new product on your online shop. The product-micro-service creates a product with all the information about that product. When the product is created and stored in the product-micro-service-db an event is published like "ProductCreatedEvent". The products-inventory-micro-service is listening to the event "ProductCreatedEvent" and saves information about that Product to the product-inventory-micro-service-db(something like the number of products, availability per shop and so on). After the product-inventory-micro-service includes the Product in its inventory then that product is available for selling. At this point customer can put that product to the the shopping cart. Coming back to the creation of product. The fact that when you create a Product it does not have to be instantly shown in the inventory. From the business prospective you can live with a situation where the product that you have just created appears in the inventory(eventually) with some delay of 50ms,100ms,1s.10s or 10 minutes. Even if the product-inventory-micro-service was down during the time of creation of the product it does not stop the product creation operation. As soon as the product-inventory-micro-service is up and running it will process the "ProductCreatedEvent" and the Product will be available for selling.

This 2 operation examples are simplified to just give you an example that there could be different use cases. Of course you can do this in different ways but the Ideas was to give you an example. You can see that this 2 operations that have quite different business context can be done in 2 different ways based on the business needs.

I know that using Rest API the services will be more depanded each other so, can we say we should always avoid that and use AMQP?

Definitely no. A distributed system using micro-services will have operations which will require the usage of direct calls from micro-service to micro-service over an Rest API some some other protocol like SOAP(or some other protocol). Sometimes you need to have synchronous and blocking call. Probably for most operations and business domains this is a rare case but still it is very important to have that as an option when you need it. You can read in this answer here about ways how micro-services can communicating between each other.