EIP Event-driven Message Types
In Enterprise Integrations there are many types of messages that a Sender will send to a Receiver. These can broadly be categorised as Command, Event and Query messages.
In most modern systems, the three are often interchangeable. For instance, Apache Kafka is capable of sending a single message that is a Command, Event and Query. Even though this is possible, the rule of separations of concern should be applied here.
In this post, I detail the differences between the three.
A Command message sent by a Sender instructs a Receiver to do something. For example, if a customer creates an order, the Order service will send a Command message to a CRM system instructing the CRM to create a new Order record that is associated with the customer.
Properties of a Command Message:
- Command messages are sent with intent.
- Command messages only have a single Sender and Receiver. This is unlike an Event message where multiple receivers can consume messages.
- Creates a tight coupling in some instances. A Command message is bound to a Receiver.
- Commands will often carry all the data in a Payload. If the data is too large, integration patterns such as Claim-Check are used.
- Delivery guarantees are crucial to ensure that the message is delivered to the Receiver.
- Command messages are named as verbs (CreateCustomerOrder).
Event messages advise other systems that something has happened. For example, an IoT device may send streaming events to a Receiver that displays the data stored in the message in a reporting dashboard.
Properties of an Event Message:
- Event messages represent something that has happened in the past.
- Event messages never change, they are immutable.
- Event messages are common in asynchronous architecture (Pub/Sub).
- Event messages can have multiple Receivers or non at all.
- Different Receivers can react to messages independently.
- Events are light-weight in size compared to a Command message.
- Event messages are past tense.
While Command messages instruct a system to do something; Query messages ask a Receiver to return something. For example, in RESTful services, a Sender may request some information via a message, and the Receiver will invoke the necessary actions to send some information back to the Sender with the correct response codes.
Properties of a Query Message:
- Contains details of the Sender so that the Receiver can send a response.
- Query messages are often synchronous.
- Query messages are often used in a Request & Response type architecture.
- Query messages are often implemented over protocols such as HTTP or RPC.
- Query messages do not change state, they request informaton.
- Use Command messages when you need a single Receiver to invoke a function.
- Use a Command message when you need a synchronous response sent back to the Sender.
- Use Content Enricher or Claim Check patterns to augment messages.
- Command messages are often used in Point-to-point integrations or Microservices architecture.
- Command messages should be used in scenarios where an Orchestrator or a Choreography architecture is used.
- Use Event Messages when there is more than one Receiver.
- Event Messages are often combined with Broadcast patterns.
- Event messages should be used in Publisher/Subscriber Architectures (Event-Driven Architectures).
- Event messages should be used in Streaming analytics scenarios.
- When de-coupling is a higher priority.
- Good to use in a Fire and Forget pattern.
- Query messages are primarily used in HTTP requests, if the service you are constructing requires a request to be fulfilled with the Sender sending back a response then use a Query message.
- Query messages are often used to query DNS data.
- Query messages are synchronous; so if an immediate response is required Query messages should be used.