Topics

Types of communication among microservices

In a microservices architecture, there are typically three types of communication patterns used for inter-service communication:

  • Synchronous
  • Asynchronous
  • Data streaming [point to point]

1. Synchronous communication using REST

1.1 Handling failures

  • by using Circuit breaker pattern
  • Network timeout if do not receive response within a configured timeout
  • Limit the number of outstanding requests from a client to a target service

👉 Pattern: Circuit Breaker. See

Netflix Hystrix is an open source library that implements these and other patterns. If you’re using the JVM, you should definitely consider using Hystrix when implementing RPI proxies.

1.2 Recovering from an unavailable service

How do you respond to a call when your dependent service is down depends on the case you are implementing.

Though, there are following options:

  • Return error to the client telling your dependent service is down
  • Return a default response or the last cached value
  • Keep the requests stored and respond the client that request is stored and will be procedded later. Keep an API which can be invoked to check the status of stored requests.

1.3 Service discovery

A service should never call another service directly, though it should search the service by name and should get the endpoint of that service.

👉 Pattern: Service Discovery. See

Service discovery works in one of given four ways:

2. Asynchronous messaging

A client invokes a service using asynchronous messaging.

👉 Pattern: Messaging. See

2.1 Message

A message consists of a header and a message body. See

There are several different kinds of messages:

  • Document : A generic message that contains only data. The receiver decides how to interpret it. The reply to a command is an example of a document message.- Command : A message that’s the equivalent of an RPC request. It specifies the operation to invoke and its parameters.
  • Event : A message indicating that something notable has occurred in the sender. An event is often a domain event, which represents a state change of a domain object such as an Order, or a Customer.

2.2 Message Channel

Messages are exchanged over a channel. A Sender sends a message over a channel on a location [called queue or topics]

👉 Pattern: Message Channel. See

2.3 Message brokers

When selecting a message broker, you have various factors to consider, including the following:

  • Supported programming languages — You probably should pick one that supports a variety of programming languages.
  • Supported messaging standards — Does the message broker support any standards, such as AMQP and STOMP, or is it proprietary?
  • Messaging ordering — Does the message broker preserve ordering of messages?
  • Delivery guarantees — What kind of delivery guarantees does the broker make?
  • Persistence — Are messages persisted to disk and able to survive broker crashes?
  • Durability — If a consumer reconnects to the message broker, will it receive the messages that were sent while it was disconnected?
  • Scalability — How scalable is the message broker?
  • Latency — What is the end-to-end latency?
  • Competing consumers — Does the message broker support competing consumers?

✋ In a brokerless architecture, services can exchange messages directly. ZeroMQ (http://zeromq.org) is a popular brokerless messaging technology. It’s both a specification and a set of libraries for different languages. It supports a variety of transports, including TCP, UNIX-style domain sockets, and multicast.

2.4 Possible ways of interactions using messages

  • Request Response
  • One way event sending
  • Publish Seubscribe
  • One way push notification

2.5 Benefits of Broker based messaging

  • Loose coupling — A client makes a request by simply sending a message to the appropriate channel. The client is completely unaware of the service instances. It doesn’t need to use a discovery mechanism to determine the location of a service instance.
  • Message buffering — The message broker buffers messages until they can be processed. With a synchronous request/response protocol such as HTTP, both the client and service must be available for the duration of the exchange. With messaging, though, messages will queue up until they can be processed by the consumer. This means, for example, that an online store can accept orders from customers even when the order-fulfillment system is slow or unavailable. The messages will simply queue up until they can be processed.
  • Flexible communication — Messaging supports all the interaction styles described earlier.
  • Explicit interprocess communication — RPC-based mechanism attempts to make invoking a remote service look the same as calling a local service. But due to the laws of physics and the possibility of partial failure, they’re in fact quite different. Messaging makes these differences very explicit, so developers aren’t lulled into a false sense of security.

2.6 Downside of Broker based messaging

  • Potential performance bottleneck — There is a risk that the message broker could be a performance bottleneck. Fortunately, many modern message brokers are designed to be highly scalable.
  • Potential single point of failure — It’s essential that the message broker is highly available—otherwise, system reliability will be impacted. Fortunately, most modern brokers have been designed to be highly available.
  • Additional operational complexity — The messaging system is yet another system component that must be installed, configured, and operated.

2.7 Handling duplicate messages

  • Write Idemotent message handlers
  • Track messages and discard duplicates

2.8 Message ordering

2.9 Transactional messaging

  • Using database table as message queue

✋ Pattern: Transactional outbox. See

  • Publishing events by using the Polling publisher pattern

✋ Pattern: Polling publisher. See

  • Publishing events by applying the Transaction log tailing pattern

✋ Pattern: Transaction log tailing. See

Few examples: