Communication between microservices - request data

Question

I am dealing with communication between microservices.

For example (fictive example, just for the illustration):

• Microservice A - Store Us

Answer 1

It all depends on your service's communication behaviour to choose between REST APIs and Event-Based design Or Both.

What you do is based on your requirement you can choose REST APIs where you see synchronous behaviour between services and go with Event based design where you find services needs asynchronous behaviour, there is no harm combining both also.

Ideally for inter-process communication protocol it is better to go with messaging and for client-service REST APIs are best fitted. Check the Communication style in microservices.io

REST based Architecture

• Advantage

  1. Request/Response is easy and best fitted when you need synchronous environments.

  2. Simpler system since there in no intermediate broker

  3. Promotes orchestration i.e Service can take action based on response of other service.

• Drawback

  1. Services needs to discover locations of service instances.

  2. One to one Mapping between services.

  3. Rest used HTTP which is general purpose protocol built on top of TCP/IP which adds enormous amount of overhead when using it to pass messages.

Event Driven Architecture

• Advantage

  1. Event-driven architectures are appealing to API developers because they function very well in asynchronous environments.

  2. Loose coupling since it decouples services as on a event of once service multiple services can take action based on application requirement. it is easy to plug-in any new consumer to producer.

  3. Improved availability since the message broker buffers messages until the consumer is able to process them.

• Drawback

  1. Additional complexity of message broker, which must be highly available
  2. Debugging an event request is not that easy.

Answer 2

Personally I am not a fan of using a message broker for RPC. It adds unnecessary complexity and overhead.

How do you host your long-lived RabbitMQ consumer in your Users web service? If you make it some static singleton, in your web service how do you deal with scaling and concurrency? Or do you make it a stand-alone daemon process? Now you have two User applications instead of one. What happens if your Users consumer slows down, by the time it consumes the request message the Orders service context might have timed-out and sent another message or given up.

For RPC I would suggest simple HTTP.

There is a pattern involving a message broker that can avoid the need for a synchronous network call. The pattern is for services to consume events from other services and store that data locally in their own database. Then when the time comes when the Orders service needs a user record it can access it from its own database.

In your case, your Users app doesn't need to know anything about orders, but your Orders app needs to know some details about your users. So every time a user is added, modified, removed etc, the Users service emits an event (UserCreated, UserModified, UserRemoved). The Orders service can subscribe to those events and store only the data it needs, such as the user address.

The benefit is that is that at request time, your Orders service has one less synchronous dependency on another service. Testing the service is easier as you have fewer request time dependencies. There are also drawbacks however such as some latency between user record changes occuring and being received by the Orders app. Something to consider.

UPDATE If you do go with RabbitMQ for RPC then remember to make use of the message TTL feature. If the client will timeout, then set the message expiration to that period. This will help avoid wasted work on the part of the consumer and avoid a queue getting backed up under load. One issue with RPC over a message broker is that once a queue fills up it can add long latencies that take a while to recover from. Setting your message expiration to your client timeout helps avoid that.

Regarding RabbitMQ for RPC. Normally we use a message broker for decoupling and durability. Seeing as RPC is a synchronous communication, that is, we are waiting for a response, then durability is not a consideration. That leaves us decoupling. The question is does that decoupling buy you anything over the decoupling you can do with HTTP via a gateway or Docker service names?

Answer 3

In your case using direct REST calls should be fine.

Option 1 Use Rest API :

When you need synchronous communication. For example, your case. This option is suitable.

Option 2 Use AMQP :

When you need asynchronous communication. For example when your order service creates order you may want to notify product service to reduce the product quantity. Or you may want to nofity user service that order for user is successfully placed.

I highly recommend having a look at http://microservices.io/patterns/index.html