Basics of event messaging

3 min readJun 8, 2020

I had a task to transfer events between services using a message-broker. It was rabbitMQ in my case. I had never met this task before, so I decided to dive deep into the messaging theory and find out how the same has been implemented in different projects in Github. Unfortunately, I had a lack of knowledge of the terminology in this area, and that made it difficult to find the required information.

This article is my compilation of the most important terminology and approaches found by me in the area of events transfer between services by broker service. I don’t pretend that all terms in this article are scientifically right and have the correct name. But knowledge of them will surely make easier your continued search of event messaging information.

Messaging.

Let’s start. The data transfer between services is called Messaging.

The part of your application sending a message is called Producer. The one who receives a message is called Consumer.

Types of messages.

All messages can be divided into 3 types:

Events. The message contains information about something that has already been happened.
Command. This type of message requests to do something from another service, e.g. one service asks to run an email sending from another service.
Query. The message that requests the data.

Message Bus.

The communication between a service and a message broker can be implemented using the Message Bus pattern

This is the definition of Message Bus from the book ‘Enterprise Integration Patterns’.

A Message Bus is a combination of a common data model, a common command set, and a messaging infrastructure to allow different systems to communicate through a shared set of interfaces. * Enterprise Integration Patterns book.

Depending on the transfer message type all buses are separated by:

Event bus.
Command bus.
Query bus.

The bus can be synchronous and asynchronous, i.e. the producer waits for a response or doesn’t.

Poisoned message.

If the consumer does not recognize the income message as a valid one, e.g. it doesn’t contain all the required data. Then this not valid message is called “Poisoned message”

Dead letter queue.

If the service recognizes that the message is “Poisoned”, then the app has to move this one to a separate queue which is called “Dead letter queue”. Then you have to decide what to do with the messages from this queue. For example, you can just log them.

Event message requirements.

There exist some “best practice” requirements for an event message.

Immutable. If the message is created, then it won’t be changed.
Unique identifier. Sometimes, you need to distinct events between each other, e.g. when you need to check if the event has already been handled by the service in the case of duplication.
Created at (timestamp). When the event was created.
App Identifier. Identification number of the service that has produced the message.

Bonus section.
3 ways how to implement event messaging.

I’ve found in books and articles 3 ways how to implement the event messaging based on RabbitMQ message-broker.

Send all events in one queue. Every event must contain a field “type” where the concrete name of the event is placed, e.g. “userAdded’. The consumer side has only one listener for all events of the queue. And it decides how to handle events based on “type” value (switch — case way).
Each event type has its own separate queue. The consumer side has a listener for each queue.
All events grouped by some characteristics. For example, grouped by belonging to a model (the group of users events, group of the document events, and so on). Each event group has its own Exchange in RabbitMQ where consumer sends all events from this group. The consumer sends an event with parameter route_key. The exchange has a bind between route_key value to the required queue. As a result, all events will be routed to the required queue. Each queue has a separate consumer.

Some most helpful sources: