When we talk about events in an event-driven architecture (EDA), we are referring to unusual or important actions or incidents (i.e., changes in state) that occur in the system generated by the system’s software or hardware components. For the purposes of this article, when we refer to an event, we mean an event notification (the notification that something has changed). As the event is generated in one of the architecture components, and the notification placed in the event management bus, the communication pattern used to share the notification between the components also defines the nature of the message enclosing the event.
In event-driven architecture, various events are broadcast across the event management bus. If you step back and look at all the asynchronous data, you will find more than just notifications. You also will find common communication types that should be taken into consideration when designing a proper cloud-native EDA.
Based on the type of communication, events should be handled differently in order to achieve best performance and flexibility. Suitable processing and communication technologies should be chosen according to the type of events encountered; there is no "one size fits all" solution.
Event
We will define a software event as the immutable record that something happened within an application. The event usually will contain the local timestamp to enable ordering to be preserved with respect to the producing application. An event may contain identifiers and state information related to a particular entity of interest. In Domain Driven Development (DDD), events are referred to as Value Objects.
Normally events are broadcast to notify of change or replicate state across multiple applications. Consumers are able to process events asynchronously; there is no need for them to be available when the event was created.
An example of an event with state information is one generated when a customer updates their address. The event will contain the customer identifier and new address (state). Consumers of the event are able to update the relevant details asynchronously—billing, marketing mailings, etc. The loose coupling allows the producing application to complete without waiting for the remote updates to apply.
Command
A command is an asynchronized form of Remote Procedure Calls (RPC) in which the message contains instructions telling the consumer what to do. This may cause a change of state in the system and normally the status will be returned to the initial producer. Sometimes command events may result in complex transactions and the ability to roll back is crucial. The saga pattern of transactions is commonly used in applications making use of command events. The properties of the communication technology and timeouts must be well understood when using commands. Also note that at least one consumer must be available to process the message in an acceptable time frame.
An example of a command event might be to buy a certain number of stocks. The corresponding response event would indicate that the trade had succeeded or failed.
Query
Queries are similar to commands, except they expect a response containing the current state of an entity rather than causing state change. The query pattern is able to operate on a read-only dataset and duplicated queries are tolerated as the event is idempotent. Caches are frequently used in the query pattern to enable a faster response time and, as with commands, at least one consumer must be available to respond to the event.
Event-driven architecture
The type of events produced and consumed by your applications will be key to craft a successful event-driven architecture. To learn more on the basics of EDA, visit the event-driven architecture topic page.
Last updated: January 10, 2022