Introduction to Event Sourcing
As with any other technology product, the Event Sourcing framework works best when applied to the right use cases and with appropriate modeling. This guide is intended to provide guidance on how to get the most out of the framework and avoid common pitfalls. As you follow this process, try to keep the following tenets in mind:
- The framework is intended to make it easy to create many small, independent microservices. If your service looks like it will take more than a week to build, you should look for ways to break it up.
- Don't try to replicate object-oriented CRUD over REST or a state-oriented approach using the framework. This framework works best when paired with a Domain-Driven Design approach to modeling. This means starting with Events and looking for relationships between Entities.
- Coding is the easy part; the modeling is hard.
Before starting coding or design, it's important to keep in mind what kind of problems Event Sourcing is good at solving. The Event Sourcing framework offers the following features:
- Event and simple workflow management The framework enables you to focus on the event processing logic and automates painful plumbing work.
- Support for large scale As with other event streaming systems, even commodity hardware is capable of handling volume that far exceeds the capability of a SQL-oriented system.
- Easy schema management This allows teams to develop software with independence, safe in the knowledge that their services and tools work together.
- Built-in audit trail Every event is journaled and every action is associated with the user that performed the action.
- Replayability and high availability Internally the system uses a combination of snapshots and replays to ensure the system state is recoverable, even in a disaster recovery scenario.
These features are an excellent fit for tracking and guiding processes. Asynchronous workflows and business processes are particularly good. In general, if you want a system to track what is supposed to happen and what actually happened, the Event Sourcing Framework is a perfect fit.
Event Sourcing is not a good model for solving other types of problems. It does not help you solve optimization problems or coordinate between many different systems. Event Sourcing is also not a good candidate for problems requiring strong consistency or that deal with very abstract problems.
As an example of knowing how to split services up, consider the problem of last-mile stop sequencing. Event Sourcing is an excellent fit to schedule and track expected stop times and locations. It also helps manage changes to stop orders and will do an excellent job at tracking changes and exceptions to the planned order. However, Event Sourcing does not help determine the stop sequence itself. For the best results, keep that kind of logic outside of Event Sourcing in a separate microservice. Don't try to have the same system do both.
Use it when it's the right fit
In general, async workflow use cases make a good fit for Event Sourcing, but systems requiring strong consistencies don't.
Updated 29 days ago