Event Models – Identity
A couple of days ago I wrote a bit about event models and tried to sort out what the fundamental properties of an event are.
One of those properties seems to be the identity of an event. This property is something I see as the major defining characteristics of event processing. The thing that sets event processing apart from mere data processing.
Normally data, like tuples in a database, are all anonymous. If you insert the value 123 into a database you can’t distinguish it from another 123 in the same database. The data looks all the same. But events report on a real world events and should be unique.
Each event (instance) should have its own universally unique id!
Technically this is very easy. Just let someone, commonly the event generator, assign an UUID to the event.
But, what’s in an event id?
First of all, if we add the requirement (which I think we should) that events are create-once-never-change type of things, it is enough to use the identity of an event in place of the event itself in many cases. Events can be replicated and distributed rather easily and found by their id as the search key. Basically we can store info such as “Event with id 1939 occurred because of event with id 1914” without storing the events themselves.
I tend to think of events as “Notification about state change in some (business) entity”. With this in mind, the event id would be the id of a particular state change.
And here’s were things get tricky…
Lets say we have the event:
- Type: Collision
- Payload: Vehicles that collided
To complicate things, or rather make them more realistic, lets say this event can be reported by a number of event generator sources. This, for example, could happen because the collision is detected by a bystander, a surveillance camera and by the vehicles themselves at the same time.
So we have at least five different entities which detect the same collision.
Now, should all the entities generate an event with the same identity? After all, they are all creating a notification about the same thing?
If multiple event generators observe and report about the same event occurrence, they would obviously need to be coordinated if we require that they generate events with the same id. This is not practical or maybe not even possible. So we need some other solution for this. (hint: multi event fusion)
What if the different events describe a slightly different aspect of the collision? It’s still the same collision.
When creating event processing logic, like rules in ruleCore, you wan’t to be shielded from this problem. The rules should see only one collision! Otherwise you will easily end up in rules triggering multiple times and you have suddenly reports about multiple collisions when there in reality have been only one.
Something as simple as a event id could have a rather complex semantics and you should be aware of this when designing your event model.
Or is it just me complicating things?