What is an event, anyway?

By Software Development Team Lead, Jon Vines

We’re going to spend some time in this post dissecting what an event is in its most basic form. Building from this definition, we’ll consider why we should use events. Finally, we’ll look at what an event could look like.

Definitions

As we dive further into understanding event-driven systems and what building our architectures like this brings us, we start to think more and more about what an event is. What makes a good event? Is there one event shape to rule them all? And, what does it mean to use events?

To take it right back to the basics, I like to think of an event outside the context of technology. If we look at the dictionary definition of an event, we can define it as:

An event is something that happens, especially when it is unusual or important.

When thinking about this in the context of our application estate, we can further define an event as something that has happened, that the organisation cares about. Further, we should remember that an event reflects the past nature of the occurrence. Events are also immutable in their nature and are unable to be changed once they have occurred.

There are a few examples of events that we can draw on:

• An action that a user has taken e.g. An Order Complete event in a retail scenario
• Originating from a machine e.g. A delivery van, tracking its location as it moves
• A system event e.g. A logging event, showing duration of a transaction (think Observability)

Why events?

Events form a very natural way for us to describe how a business operates. Techniques such as Event Storming can be used to help facilitate conversations that derive business process from a series of events. These events then become the building blocks of the applications and ecosystems built to support those business processes. If we start to take these ideas to their logical extreme, we can start to see how the observation of every company becoming software becomes true.

Adopting events gives us several advantages. It also means how we build our applications significantly changes. To take advantage of events, we must become event-driven. Events become the de facto method of communication for applications built within our organisation.

From an application perspective, the use of events allows us to decouple our applications. As a producer, we can broadcast the event to anyone with the API who wants to listen. As a consumer of an event, we only listen to the events that we care about. No matter which side of the Microservices/Monolith/Services argument we fall into, this is a powerful shift in perspective. We begin to build a data ecosystem of events, which we can begin to react to in real-time.

Types of events

It’s important to note that there are different types of events. Firstly, the data being carried by the event determines the type of event we’re semantically sending. For events that describe the occurrence of something happening, we refer to this as event notification. In this scenario, we may need to query the source system to obtain the context for the event at any given time.

Alternatively, we could pass along enough data for the consuming systems to be able to derive the context of an event from the event itself. When this happens, we call this event carried state transfer.

For further definitions and in-depth discussion, please refer to Martin Fowler’s excellent post What do you mean by “Event Driven”?

On top of this, we can distinguish between domain events and system events. We referred to this earlier. A domain event is an action a user has taken or something the organisation cares about. A system event describing the transactional flow of a request or metric.

Classifying and agreeing on event definitions can go a long way to a successful event-driven ecosystem. It allows us to define a common event structure, sets us up for distributed tracing and observability across our applications and minimises cognitive load when considering how we integrate across our application landscape.

What does an event look like?

To distil these thoughts, we can look at what an event could look like. I want to emphasise the could here. This definition works for us, but it’s important that each of the properties described have meaning in the context your introducing events to.

{
  metadata: {
    correlationId,
    causationId,
    eventId,
    timestamp,
    source,
    tags [],
    headers []
  },
  data: { }
}

We have defined two high-level properties of an event. We have the data, or payload, of the event. We also have the metadata.

The payload is used to describe the domain event for a given entity. This entity has an ID and is used to give the entity its uniqueness. Subsequent events may have the same payload ID which is used to describe changes to that entity. Consumption of these subsequent events should describe the evolution of said entity.

Interestingly, the introduction of metadata gives application-specific context to the events that are happening. Metadata can be defined as data about data. We can define each property as follows:

• Correlation ID: The id of the source event triggering all subsequent new events
• Causation ID: The id of the previous event triggering the new event
• Event ID: The unique identifier for a given event
• Timestamp: The timestamp that the event occurred
• Source: A system identifier for the source of the event
• Tags: A list of tags used to help aggregate for monitoring and observability purposes
• Headers: A list of headers used to denote system behaviours on a given event (think Chaos Engineering or Synthetic events

Considering events

We believe the adoption of events and event-driven systems is both forward-looking and an organisation enabling feature for realising new, real-time experiences. We’ve spent some time looking at what an event is in its most basic form and why we should use events. Finally, we’ve spent some time looking at how an event could be composed.

It’s fair to say, we’ve only just scratched the surface of events. There’s plenty more we could talk about such as Event Sourcing, Event Streaming and Eventual Consistency. We should also consider the different technologies we can use to enable becoming event-driven.