5 important things you should know to succeed with Event Sourcing

This is a checklist of the most important things to get started on the right track for building sytems using Event Sourcing.

Mattias Holmqvist

2020-04-15

When meeting with many clients and customers over the years we’ve seen a number of things that are common pitfalls when getting into Event Sourcing (or event-driven development for that matter). We want to share our checklist for getting faster on track when building solutions using Event Sourcing.

Are you using the business language?

Events should speak the language of the domain. Make sure you formulate the events in past tense, using a language that your business people/customers/users could understand. If you do this properly the events can be used to track the story of the business back in time. It also makes discussions with stakeholders much more fruitful since you're talking about the same things.

Are the events immutable?

If the events are modified after they are saved, you're probably not doing Event Sourcing properly. There are exceptions, such as deletion of events for regulatory reasons, but in general events should be immutable, since they represent something that has happened and changing the past is not possible.

Are the events uniquely identifiable?

Every event marks a specific thing that happened. It makes a lot of sense to be able to talk about individual events and you make your life a lot easier by attaching a unique identifier to each event that you create. A good choice is to use UUIDs since it is an easy way to generate unique identifiers without some kind of synchronization between systems.

Do the events have timestamps of a common format?

All events should include some kind of timestamp referring to when the event occurred. Be careful to always use the same format/representation, preferably UTC time for any timestamps that are stored in events. This makes it easier to format them to a presentable format and reason about them.

Is the context right?

Keep the context in mind. If you have a complex system you likely have multiple services and it might be OK for them to have events of the same name but with different meaning. Learn more about Context mapping and Aggregates before building a large-scale solution that heavily depend on Event Sourcing.

Good luck!