Building systems in terms of events is one of software’s most potent ideas for influencing product design. Events, if you’re not already familiar, are a means for modeling any kind of activity. Designing with events allows you to use information you already have to ask more meaningful questions and increase the versatility of your software’s functionality.
Our industry tragically places a disproportionate amount of excitement about events on the architectural characteristics that they provide, at the expense of the concrete value they offer. Conversations quickly shift into the topics of log-oriented architectures, scalability, and eventual consistency without mention of purpose. We think this is all incredibly interesting discussion, but we need to start talking more about event-driven products, and less about event-driven architectures.
95% of the cost of event sourcing projects is explaining event sourcing— Scott Bellware (@sbellware) June 11, 2017
We believe that the narrative about events and their applications has become severely misshapen. You don’t need to have petabytes of data or millions of customers to benefit from this approach. Nor do you need to read up on data warehouses or distributed systems to start learning how to model your domain more effectively.
To that end, this post has nothing to do with storing, processing, or querying events. It has no comment on technology choices or scalability factors. This article is for product designers who want to learn the basics of modeling with these techniques, and get a glimpse into the power it can provide for their products. It’s also for engineers who understand event-driven architectures soup to nuts, but are having trouble advancing internal company conversation about why this approach is a game changer.
Events are observations
Events are an extremely simple idea - they are merely observations, or facts, that occur at a particular time in point. Every event can be characterized by exactly 4 attributes: an entity, an action, contextual information about the action, and the occurrence time. That’s it! Events aren’t a technical term, like a database record, or a protocol. They simply convey a fact of truth.
We don’t need software to think in terms of events. The stoplight outside of your office is constantly generating events. A new event occurs every time the light changes from one color to another. Consider the following table of events:
|Stoplight at 3rd & Pine||Light change||color=green||2017-10-09 12:45:00|
|Stoplight at 3rd & Pine||Light change||color=yellow||2017-10-09 12:45:45|
|Stoplight at 3rd & Pine||Light change||color=red||2017-10-09 12:45:50|
|Stoplight at 3rd & Pine||Light change||color=green||2017-10-09 12:46:15|
What’s notably absent are events about the software that controls the light, or events about cars passing through the intersection. With this example, all we care to model is the transition of colors on a single stoplight. We only need a handful of event types to describe that.
Events control resolution
Similar to YouTube’s video quality menu, events offer an opportunity to model your business activity with an arbitrarily high degree of detail. Watching a video in 240p gets the basic job done, but the experience of watching a video in crisp 4k resolution completely changes the viewing experience. In our stoplight example, we chose to omit modeling anything but the transition of the light color, which is rather low resolution. We could have just as easily captured wind speed recordings on the light post, instances of pedestrians using the crosswalk, or the transitions of other stoplights. Adding more detail via events is merely a matter of capturing more information.
|Stoplight at 3rd & Pine||Light change||color=red||2017-10-09 07:12:43|
|Stoplight at 5th & Oak||Light change||color=green||2017-10-09 07:12:44|
|Wind sensor 3rd & Pine||Wind speed recording||speed=5.6 mph||2017-10-09 07:12:48|
|Camera at 1st & Main||Crosswalk usage||crowd=5||2017-10-09 07:13:17|
What’s notable about collecting events in a tabular format, sorted by time, is that it allows you to read the table from top to bottom and learn about each entity’s growth from each row over time. The more detail in the table, the richer of a story the readers of your table will have. Events are a currency of knowledge.
It’s easy to see how capturing more information allows one to ask more meaningful questions. Suppose that you’re the author of a popular online, multi-player chess game. Every game that’s played is recorded in a database, including which player won and lost. When looking at the list of all games that have ever been played, one can learn the answers to basic questions: how many games have been played by each player, how many of those were won and lost, and so forth.
By capturing only one more event type: every move made by each player in each game, a wealth of information becomes available. If every move in every game were available, one could now not only answer all of the previous queries, but ask significantly more meaningful questions:
- What were the longest games in terms of number of moves?
- The shortest games?
- The most boring games? (number of non-piece capture moves)
By recording context about the board in each event, we can peer into the patterns of game activity much further:
- What were the most common opening moves?
- The most common closing board configurations?
- The least common remaining pieces of the winner’s board?
If we were to arrange all of the moves in every game into a tabular format and again sort by time, something incredibly interesting happens. We no longer need to record who won and who lost each game. By simply reading downward in the table, we can derive that information. The ability to independently interpret information as the reader of the events makes this a powerful approach. Observers of the events need to agree on very few details, promoting a wider versatility of use cases with the same data.
Constructing your event narrative
Much like having a picture drawn in front of your eyes, collecting and recording events reveals an image of your product activity. All you need to do is start looking for them. As a modeling exercise, try to write down as many domain events as you can think of. When we sit down to do an analysis of a domain, we find that the following list of questions can be helpful to start revealing progressively higher levels of detail:
- Who or what are the entities in my domain?
- What actions can each entity take that are independent of other entities?
- What actions can each entity take that directly involve other entities?
- Looking at any current analysis that’s done on your domain, what are the factors that contribute to the result of of each analysis?
- Does your business watch out for any anomalies? What factors contribute to those anomalies?
- Can any of my events further be broken down into sub-events?
- Are any events reversible? E.g. are there any “undo” events?
- Do any events also have an “acknowledge” or “confirmed” event, too?
- Does your domain utilize the concept of “nudging” a user into performing or not performing certain actions? What are the events that constitute the behavior you want to change?