The Microservice Dilemma: RPC, Message or Event
A typical dilemma encountered often in microservice architectures is the choice of communication method. A few choices available to us for inter-service communication are RPC, Messages and Events.
In this article, let's look at what these communication methods are and why it is hard to choose between them in some situations. We will use an application that consists of an orders microservice and an inventory microservice.
RPC
Remote Procedure Call (RPC) is a request-response protocol that fits very well with the thought processes of programmers on both the client microservice and server microservice. With the tooling available, calling a remote procedure is usually syntactically the same as calling a normal programming language procedure.
A key characteristic of RPC communication is that the client microservice identifies the server to communicate with (by specifying a host and port).
orders service invokes an RPC on inventory service:
update_inventory(item, items_sold)
Message
A message is a request from one microservice to another for an action to be taken.
A key characteristic of the message communication is that the client microservice may or may not know which service is going to receive and process the message. However, there is typically an expectation that the message will get acted upon. A messaging service provides this separation between the microservices.
orders service publishes a message to a queue named inventory_updates:
message = { type = update_inventory, item=x, sold=n }
Event
A event is a notification from one microservice of a change that has occured in the system.
A key characteristic of event communication is that the change is in the past, and the microservice is sharing this. However, there is no expectation that this event will be acted upon.
orders service publishes a event to a topic named sales:
event = { item=x, sold=n }
The Dilemma
The examples above show reasonable implementations with each communication method.
The RPC and message approaches are a good fit when there is a clear expectation of work that needs to be done by the receiver.
RPC approach can be preferred when a synchronous behavior is expected — the microservice making the RPC call needs to respond to its client only after placing the order and updating the inventory.
Messaging approach can be preferred when there is no need for a synchronous behavior. Inventory must be updated but not before confirming the order to the client.
Event approach is well suited when the order service has completed the operation itself (such as placing the order) and wants to inform zero, one or more services. The consumers of this event may perform any number of actions — updating the inventory, analyzing the user behavior or forecasting demand.
Also, note the subtle difference in naming — RPC and messages are typically a verb (update_inventory) and the topic name used for event approach is typically a noun (sales) from the domain of the application. This article does not cover the scalability, response time and other considerations in making the design choices, but hopefully provides some food for thought based on semantics of interaction between the microservices.