July 26, 2015 · data quality events

Events and Actions

When using events in your systems, it's important to distinguish between actions (a page view, a sale, etc) and the fired events that describe them. It might seem an irrelevant detail, but we'll see that we'll end up with very different systems depending on how they are related.

1. Events After the Action

Perhaps the most common case, events can be fired after an action has been completed. A typical example is page views: first the page is rendered in the user's browser and then a page view event is fired. Or the customer's credit card is charged and a sale event is fired.

So the sequence is: Trigger => Action AND Event

Benefits:

Downsides:

2. Events as Side-Effects

Another possibility is to have the event automatically fired as a consequence of an action. In this case, is the system where the action is performed that guarantees that the event will be reliably fired. Two examples are change data capture (CDC) in databases and webhooks when using third-party services.

The sequence is: Trigger => Action => Event

Benefits:

Downsides:

3. Actions as a Consequence of Events

Another solution is to send the events first and then perform the actions in response to them. In this case it pays off to use distributed commit log like Kafka, because if any of the actions fail the events can be replayed. Martin Kleppmann explains it really well in the talk Staying agile in the face of data deluge.

The sequence looks like: Trigger => Event => Action(s)

Benefits:

Downsides:

Closing Thoughts

Depending on the actions and on how the events will be used, it's usually clear which method to use. But it's important to know their trade-offs when various could be used. I would also like to point out that these methods are closely related to event-sourcing and CQRS.

Do you know more ways in which events and actions can be related?

Comments powered by Disqus