Messaging Primer: In the Age of Microservices

There are two communicating styles used by components of a distributed application:

• Synchronous request-reply
• Asynchronous messaging.

Synchronous request-reply is for requesting service from one component to another. The calling component needs the reply data or confirmation before it can proceed.

Asynchronous messaging is for handing data over from one component to other components. The sending component does not (need to) know which components will process the data, nor does it need to wait for any response (from other components) before proceeding.

For simple end-user facing, front-end/back-end type of applications, the request-reply style is usually all the application needs. For complicated enterprise applications, such as the ones with multiple interconnected back-end components, multi-level pipeline processing, asynchronous messaging has its place if not a dominant one.

In the age of Microservices, request-reply is usually conducted through RESTful APIs or alike such as SOAP, gRPC. Although asynchronous messaging could be achieved by using those protocols plus customer-built infrastructure supporting asynchronous behaviours, most people just use a message broker to avoid reinventing the wheel.

Message brokers provide two essential functionalities for building distributed applications:

• Routing
• Queuing.

Routing is the data directing function. It moves data from one component to another. The functionality could be achieved as a builtin part of the Microservice as in “smart endpoints dumb pipes”, separated into a standalone module such as the sidecar proxy in service mesh architectures, or delegated to the messaging network itself in the event mesh architecture. Like IP routing, data routing is also based on the destination info carried by itself (as part of the data). For service mesh architectures, the destination is usually the service endpoint. In event mesh architectures, the destination is the topic (or subject). Routing is the way to achieve decoupling among components of distributed software applications since one component does not need to worry about the other components, where they are, or what programming language they are written in. Also like IP routing, messaging network based routing is application agnostic, it does not have a play in business logic. The application itself has to deal with the end-to-end data processing behaviour and logic, routing just helps data movement in the most efficient way in the ever distributed world of Microservices.

Queuing is the data storing and forwarding function. Queuing is the universal technique for scheduling from CPU hardware to software application. When data is available to be processed, the component that processes the data might be busy with current processing, in that case the data will be put into a queue temporarily. When the component is free, it will fetch the next available data from the queue and process it. Queuing is the way to achieve a high performance and resilient datapath. The high performance comes from that fact that queuing enables concurrent processing, while the consumer of the data is processing it, the producer could work on producing new data. The resilience comes from the fact that queuing prevents the propagation of faults and imperfect conditions (such as extra delay, temporary failure) from one component to another. Queuing is not the solution for absorbing prolonged failure. It may play a role as a temporary storage of data, but not the replacement of a database either. Although there is a concept of persistent data in most messaging brokers, its purpose is for fault tolerance, not meant to be as the solution for data store. For example, if you use event sourcing as part of your Microservice design, an event store would be the right choice instead of using a message broker for that purpose. You want to keep the event logs forever but keep the pipelines relatively empty within the messaging network.

Routing and queuing are two fundamental functionalities needed for constructing a high performance datapath of distributed software applications. Together with guaranteed sequencing and delivery, a messaging network is a choice for achieving those functionalities you cannot afford to ignore.