Best practices to communicate between microservices

Communication types

  • Synchronous protocol: HTTP is a synchronous protocol. The client sends a request and waits for a response from the service. That’s independent of the client code execution that could be synchronous (thread is blocked) or asynchronous (thread isn’t blocked, and the response will reach a callback eventually). The important point here is that the protocol (HTTP/HTTPS) is synchronous and the client code can only continue its task when it receives the HTTP server response.
  • Asynchronous protocol: Other protocols like AMQP (a protocol supported by many operating systems and cloud environments) use asynchronous messages. The client code or message sender usually doesn’t wait for a response. It just sends the message to a message broker service e.g, RabbitMQ or Kafka (if we’re using event-driven architecture).

Why you should avoid Synchronous protocol

  • If you keep on adding new microservices that are communicating with each other then consuming endpoints within code will create a mess especially when you have to pass extra information in the endpoint. e.g, auth token.
  • You have to wait for the time-consuming calls to get a response.
  • If the response fails and you have a retry policy in place then it can create a bottleneck.
  • If receiver service is down or not able to process the request then we want to wait until the service is up. e.g, In e-commerce site, user places an order and request is sent to shipment service to ship the order, but shipment service is down and we lost the order. How to send same order to shipment service once it's up?
  • The receiver might not be able to handle a lot of requests at a time, so there should be a place where requests have to wait until the receiver is ready to process the next request.

How to use RabbitMQ to handle communication between microservices

Image explains where rabbitMQ will fit in microservices
RabbitMQ Exchange

Exchange types

Direct exchange delivers messages to queues based on the message routing key. This is the default exchange type.

  • order.logs.customer
  • order.logs.international
  • order.logs.customer.electronics
  • order.logs.international.electronics

Implement RabbitMQ

Installation

Follow this link to install RabbitMQ on windows. After installation RabbitMQ service will be up and running on http://localhost:15672/. Enter ‘‘guest’’ in username and password to log in, and you’ll be able to see all statics.

RabbitMQ dashboard

Create sender service

Once RabbitMQ is up and running, create two console applications

  1. Sender: To send messages to RabbitMQ
  2. Receiver: To receive messages from RabbitMQ
The above code will create a connection to RabbitMQ, creates a queue ‘hello’ and publishes a message to the queue.
The above code will create a connection to RabbitMQ, create a queue (if it’s not created yet), and register a handler that will receive and process the message.

NserviceBus Configuration:

Summary

Avoid Synchronous protocol while communicating between services. Use RabbitMQ to communicate between services and to save messages temporarily before they’re delivered from source to destination. Use NserviceBus to decouple application code and message broker, and to manage long-running requests.

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Irfan Yusanif

Irfan Yusanif

Software Engineer based in London