What Aren’t Events?

Despite the hype around ‘Event-Driven Architecture’ (EDA) over the past few years, I am confident that you will be unable to find a solid definition for ‘Event,’ on the web today. After an hour of research, the best definition I managed to find is one of several definitions provided by Red Hat: “We will define a software event as the immutable record that something happened within an application… Normally, events are broadcast to notify of change or replicate state across multiple applications.” Here, Red Hat are talking specifically about ‘Software Events’: each of which signals a ‘change of state’ in a particular ‘entity’ (e.g. Customer address changed) within a given distributed application.

This definition perhaps seems very straightforward, but what is not mentioned, is that there are in fact three different types of ‘Events’ according to today’s pundits:

1. Notification Events: These carry no more than the key identifiers of the entity that was changed (e.g. Customer ID) in order to “notify of change” – but clearly in no way to “replicate state across multiple applications,” as state changes are entirely absent from the event payload. An additional call to the source system is in fact required by each individual event consumer, to (attempt to) determine precisely which state changes were made.
2. [Event-Carried State Transfer/Decision] Events: These carry only those attributes of the business entity that were actually changed – without any doubt the sweet spot in the world of EDA and something that is slowly becoming the norm for good reason.
3. Data Events: These carry the entire current ‘state’ of the business entity that was changed, making it very simple to “replicate state across multiple applications,” but extremely difficult to know precisely which attributes were changed.

Given that we have defined (Software) Events as an “immutable record that something happened within an application,” I am happy to go so far as to disqualify ‘Notification Events’ entirely as true ‘Events:’ They contain nothing other than the entity’s key, which we never change, and nothing else that might be referred to as “immutable.” Indeed, if there are two separate consumers of a ‘Notification Event,’ and they each make their callbacks to the source system at different times to determine what changes were made to the relevant entity, they can both indeed receive different results given that subsequent changes might have been made to the same entity between the two calls: hardly an immutable record.

What is even more interesting, is that if we consider Microsoft’s definition of ‘Event,’ we read that: “An event is the smallest amount of information that fully describes something that happened in the system.” As such, according to Microsoft, we just eliminated ‘Data Events’ as well, as these contain all of the changed entity’s attributes, regardless of whether or not changes were made to those attributes: far from “the smallest amount of information that fully describes something that happened.” This now leaves us with only ECST/Decision Events, or what I prefer to call quite simply ‘Events,’ and the EDA universe becomes clearer.

We also see loose, and even factually incorrect use of the term ‘Event’ in the world of IoT. We are told that IoT devices generate massive numbers of ‘Events’ each day, above all in the context of ‘Streaming Analytics’ use cases. These ‘IoT Events’ are said to result from, for example, regular, high-frequency temperature and velocity readings of a conveyor belt motor, needed to facilitate ongoing Streaming Analytics: in order to detect discrepancies between readings over a rolling window of time. What should be entirely obvious, is that the temperature and velocity readings for the same motor can and indeed should be identical for the most part, meaning there is typically no “change of state” whatsoever between the large majority of corresponding ‘IoT Events.’ This is precisely why ‘IoT Events’ – unlike EDA-relevant ‘Events’ – typically aren’t even persisted: they are of little to no value outside of the timeframe that is being analyzed.

This might all seem quite trivial, but if we can’t even arrive at a common definition for what an ‘Event’ is, then we have no chance whatsoever of clearly defining ‘Event-Driven Architecture.’ Therefore, above and beyond my previous analysis of the three most often discussed event patterns, we must also learn to separate ‘IoT telemetry’ – which generates millions of immediately analyzed, non-persisted records – from any resultant ‘Events,’ which in most cases are generated by concerned Streaming Analytics solutions – and not by the IoT devices themselves – to signal a significant change of state (e.g. Motor high temperature exceeded). Only the latter will typically be persisted; only the latter are ‘Events.’

In a separate, alternative definition of ‘Event’ provided by RedHat, we read that “An event is any significant occurrence or change in state” in a system. This is quite interesting because a “change in state” in itself undoubtedly represents a “significant occurrence,” which suggests that we must also consider any other “significant occurrence” that might be anticipated. This makes me think first of all of the worlds of web development, where we often hear talk of ‘UI Events.’ If the user clicks on a button to trigger an action, has there been a ‘change of state’ to the UI? Not at all, but it can be said that there was a “significant occurrence.” On the other hand, if the user also entered a response into one of the fields shown on the UI, then there was indeed a change to the UI’s state. Each of these UI examples seems to meet this second Red Hat definition of an ‘Event,’ yet it must be pointed out that a Distributed Application as a whole has no interest whatsoever in the events that are occurring on individual user PCs, in individual user applications.

So what of ‘System Events,’ such as ‘Audit Events’ when an application user accesses sensitive data or enters an incorrect password three times? Whilst each of these examples undoubtedly represents another category of ‘Software Event,’ the Distributed Application as a whole is typically uninterested in such events. Given this, we must conclude that the lifeblood of EDA – the modern architecture used to build distributed applications – is one, and only one type of event: ‘Business Events’ – "the smallest amount of information that fully describes" a 'Change of State' in a Business Entity.