Developers' Tips For Event Sourcing & Event-Driven Architecture

If you’ve read our Beginner’s Guide to Event-Driven Architecture (EDA) and Beginner’s Guide to Event Sourcing, you’re probably ready to start building your first event-driven application. The Event Store team put their heads together to come up with a list of tips that can give you the best start. 

1. Know your business domain

This is one of the most important aspects: make sure your architecture aligns with the business practices as closely as possible. Get input from business stakeholders and end users right from the start. Once you have as much information as you can gather, run an Event Storming session or an Event Modeling session to explore the domain. These sessions are a great starting point. Include your company stakeholders and end users in these sessions, and make sure you are all using the same taxonomy. The more time you invest upfront trying to learn the domain, the more chance you have of creating a successful solution. 

2. Make a versioning strategy

Greek Philosopher Heraclitus said ‘the only constant in life is change’. You may have made the best system ever, but at some point, changes will have to be made to it. A versioning strategy, taking into account future changes to your events, is essential for useful protection against legacy issues in the future.

This isn’t asking you to gaze into a crystal ball and plan for any and every eventuality with the data; just consider the complete journey of the data and create a versioning strategy accordingly. Greg Young says:

A new version of an event must be convertible from the old version of the event. If not, it is not a new version of the event but rather a new event.

Keep this in mind when creating a versioning strategy. If it is causing you a significant headache to convert the old event into a new version of that event, then you don’t have a new version of it, you have a new event. Each stage the event can go through in your workflow needs to be considered when creating your versioning strategy. Keep in mind that you must deal with all versions of the events since the birth of your application. You can learn more about versioning in this book: Versioning in an Event… by Gregory Young.

3. Do not append and publish events in the same process

When building an event-driven system for the first time, this mistake appears often. It’s a mistake that seems harmless at first until it causes problems. There is one consistent rule to development of any kind, and that is that at some point, there will be a system failure. The good news is that building systems with events are the best way to have resilience and recover from these failures.

Let’s take a seemingly simple process to code. When creating a process between two services, it can seem efficient to have the process save an event and then publish an event, both within the same process. Both tasks need to be done, both should be done at the same time, right?

There will be a time, however, when a system failure will occur between those two steps. On some ordinary day, something will happen out of the blue to mess with your system. The process will be stopped between saving the event and publishing the event, causing significant issues for your event log. If the process saves an event but doesn’t publish it, this can also cause significant problems, as there will be an event outside of the event log. If the process is the other way around, you will have an event that has been published that has been saved, making it a phantom event. Both of these scenarios are incredibly difficult to fix. 

The good news is, you can structure any process in your system to prevent this from occurring.  Appending an event to an Event Store database (like the database designed for this EventStoreDB) and then a second process that listens to the database for a save instruction. Once the save instruction has been heard, the process will publish the event. 

Breaking the processes down in this manner means that, if (and when) there is a system failure at the moment between appending and publishing, it can be fixed easily and recovered quickly/automatically. This may seem like a manifestation of Finagle’s Law, but believe us when we say we have seen processes that both append and publish events together cause problems many times. Our advice is to always separate them into separate processes to save yourself future late nights. 

Break down each step into its own process, and have each process do just one task. This will protect some parts of the system from wider failure and will make it much easier to maintain and scale up.  

4. Do not rely on the timestamp for ordering

One of the first mistakes often seen by the Event Store team is that someone decides that the sequence number should be a time stamp. It’s easy to read by the human eye, efficient and seems logical. It’s also a huge mistake with frustrating consequences for your team. 

The only way the timestamp could be used as the sequence number is if time is absolute across all systems and connections. Time may be a constant in the grand scheme of the Universe but within computers, it’s unique to every system. Just look at your watch and your car clock: they will not tick over to new minutes at the same time. There will always be differences in recorded time between systems. This difference makes the timestamps ineligible as a sequence number. Use a sequential number starting with the very first event. It’s harder to look when searching for a specific event, but it’s much, much easier than having to understand relativity.

Hopefully, these tips can give you a great start on your Event Sourcing or EDA project and help you avoid some common mistakes. If you want to talk to the Event Store team about how we can help you with this, contact us and we’ll be happy to help. 

Want more tips? Watch our webinar 'Developer tips to get the most from Event Sourcing'.