EIP – Event-Driven Consumers

Summary

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.

Command Message

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:

  1. Command messages are sent with intent.
  2. Command messages only have a single Sender and Receiver. This is unlike an Event message where multiple receivers can consume messages.
  3. Creates a tight coupling in some instances. A Command message is bound to a Receiver.
  4. Commands will often carry all the data in a Payload. If the data is too large, integration patterns such as Claim-Check are used.
  5. Delivery guarantees are crucial to ensure that the message is delivered to the Receiver.
  6. Command messages are named as verbs (CreateCustomerOrder).

Event Message

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:

  1. Event messages represent something that has happened in the past.
  2. Event messages never change, they are immutable.
  3. Event messages are common in asynchronous architecture (Pub/Sub).
  4. Event messages can have multiple Receivers or non at all.
  5. Different Receivers can react to messages independently.
  6. Events are light-weight in size compared to a Command message.
  7. Event messages are past tense.

Query Message

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:

  1. Contains details of the Sender so that the Receiver can send a response.
  2. Query messages are often synchronous.
  3. Query messages are often used in a Request & Response type architecture.
  4. Query messages are often implemented over protocols such as HTTP or RPC.
  5. Query messages do not change state, they request informaton.

Message Selection

Command Messages

  1. Use Command messages when you need a single Receiver to invoke a function.
  2. Use a Command message when you need a synchronous response sent back to the Sender.
  3. Use Content Enricher or Claim Check patterns to augment messages.
  4. Command messages are often used in Point-to-point integrations or Microservices architecture.
  5. Command messages should be used in scenarios where an Orchestrator or a Choreography architecture is used.

Event Message

  1. Use Event Messages when there is more than one Receiver.
  2. Event Messages are often combined with Broadcast patterns.
  3. Event messages should be used in Publisher/Subscriber Architectures (Event-Driven Architectures).
  4. Event messages should be used in Streaming analytics scenarios.
  5. When de-coupling is a higher priority.
  6. Good to use in a Fire and Forget pattern.

Query Message

  1. 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.
  2. Query messages are often used to query DNS data.
  3. Query messages are synchronous; so if an immediate response is required Query messages should be used.