In an event-driven architecture, there are different type of message which is used for different purposes, and usage scenario for each of them are different. Let’s dig into the details and see the use cases for each message type. A message consists of two main sections: Metadata and Payload.
Metadata
The metadata section mostly consists of information about the message publisher, message correlation ID, Timestamp, event ID, routing address, etc. which is usually used by message consumers to do some actions like finding related messages through CorrelationId, checking Idempotency, checking message expiry time, etc. There is no mandatory specification about the information in the metadata because each system or scenario can be varied, but discussing the details of message metadata is out of the scope of our article, so let’s dive into the payload part.
Payload
Message Payload or Message Body contains all information about the events, for instance, if a message is about informing other services when a new product is created, the body would contain information about the product, such as ProcutId, Price, Creation TimeStamp, Category, etc. But again same as the metadata part there is no mandatory specification about the required information in this section and completely depends on the consumer of the message and scenario, but when we see the body structure for messages we would categorize them is four major types:
- Commands
- Events
- Documents
- Queries
Now let’s review the use cases and attributes for each of these messages separately.
Command Message
Typically this message is in order to perform an action, This message also can be used to direct calls through a Rest API call.
Attributes
1- It is named with a verb in an imperative form.(eg, CreateProductCommand)
2- It is a request to a single service or aggregate to perform an action.
3- It can be rejected or fail during performance or validation, necessitating compensation actions on the publisher’s side.
Event Message
To notify other services or other aggregates that something has happened in one aggregate or service.
Attributes
1- It is named with a past participle verb form.(eg, ProductCreatedEvent)
2- Are used to pass information throuout the architecture.
3- Are not liable to be rejected.
4- Most common block of evenr-driven architectures.
5- Are able to readily accommodate new consumers in future.
Document Message
Are much like events but contain all information about an entity, unlike the events that just include required information about the changes that have happened.
Attributes
1- It contains all infromation about an entity or aggregate.
2- It is named with a EntityName plus Document word. (eg, ProductDocument)
Query Message
It is a request for information issued to a given system to obtain the service’s data. Typically, they aren’t messages and are often synchronous requests like an HTTP request. They also don’t change state; they simply request information.
Attributes
1- It mostly contains just the identifier of the requested data.
2- return some data, does not modify any.
2- It is named with a Verb plus data type plus Query word. (eg, GiveUserPurchaseHistoryQuery)
Now Let’s put together all message types and see them in a real work example in an event-driven architecture.
Final thought
I just read Hugo Filipe Oliveira Rocha’s great book, “Practical Event-Driven Microservices Architecture.” It mainly discusses challenges in event-driven systems. I thought it would be useful to share some ideas with you all. I hope you can read the whole book and learn as much as possible from it, I will also write a review of this book soon, If you are interested in this kind of material you would also like to read my article about A Short Review of “Building Evolutionary Architectures” book . Stay tuned … 🧠
Cheers, Matt Ghafouri
