Here be Events
Event is one of those wonderfully overloaded terms we using in the world of computing. Combine event with another genereic term, namely processing, and you have a brand new world of new tools and vendors all trying to sell event processing solutions to you.
Basically this means that more or less anything can be called event processing. Some vendors have already begun this magic marketing trick and starts calling various random bits and pieces for event processing solutions and puts the CEP (Complex Event Processing) label to just about anything to see if sticks.
But Event Processing have a very specific meaning and is actually something new. Not 15 years old as some vendors would try to make you believe. As CEP moves up the hype cycle expect just about anything be redressed as CEP and resold as something brand new.
In order find the right tool for the right job it’s rather important to understand some basic characteristics of the field we call (Complex) Event Processing.
Events are not just a special type of data structure. If they were, you could just handle them as data using your traditional and more well known tools.
First of all, events happen. Data is created and modified.
Events are actually a notification about some detectable activity. The activity can be virtual or something that happens in the world around us.
- Example of activity -
Door opened - page printed - ping failed - process started - elevator stopped - train arrived
The fact that an event describe some activity which just happened is the main difference with plain old data. This actually makes event and data semantics very different. Events are much more complex and on a higher abstraction level.
Let’s see what follows from the simple fact that we are describing something that happens:
- Things happen at a particular point in time. Thus the event must have an exact timestamp. A data item is not related by itself to time in any way. If you insert data into a database, the insert itself has a timestamp attached to it, but the data does not.
- Events are also related to each other in time. Data is not. If looking at two values in a database you can not, by looking at the values alone, determine which one was created first. Events on the other hand have this property as they are created at particular times.
- Multiple events can’t happen at an exact point in time. If you think they do, your timer resolution is too low. In any practical setting you might need to deal with two events which seems to happen at the same point in time even if events actually can’t happen simultaneously.
From that follows a number of interesting properties. For example it is always possible to determine if an event have occurred before another one. Also the duration between two events is easily calculated.
The fact that events are temporally related and created at specific points are one of the single factors which makes event processing a bit tricky with traditional data processing tools.
Another interesting feature (see last post) of an event is that they have a globally unique id, often implemented using uuid.
The fact that an event describes something that happened a while ago also means that once an event is created it can’t be changed. Changing it would imply that the history changed. There is also no way to, at least conceptually, delete an event. For practical purposes you would of course allow removing old events. If an event happens, it happens. Nothing to do about it. A data item can on the other hand exist for a short period of time and then vanish. The action of deleting an data item on the other hand could lead to the generation of an event. That event can’t magically disappear as it describes an historical events, and as far as I know you can’t change history.
This is a few more characteristics of an event processing solution you could look for in order to understand it the system is actually processing events or normal data. If you really need event processing, select a true event processing solution and not a re-named data processing tool.


