Event Sourcing is a pattern the stores events in order, in a append-only log.

This can enable various use cases like keeping audits of changes, compliance requirements, deriving state from events, replaying and debugging.

Many applications query for the current state and we mutate that state but sometimes we need to know the story/history of how the current state got there. Storing events using Event Sourcing provides a pattern to help us understand how the current state of the application got to where it is.

As events occur within the system, they are captured and stored. Application state can be calculated using these events, even if you have a clean starting point, you can see previous events, and calculate the current state.

Store events in append-only log

• At the heart of event sourcing, you store your events in an append-only log.

• You read/write from this log and it is discouraged to delete/update any past events.

• Any changes to events, are just new events onto the log, that way all mutations are captured in the log.

• Great example of this is accounting ledger. Accountants want to track transactions made and these are recorded.

Derive state from events

• As the data is captured as events within a log, this log can be viewed/processed to calculate state.

• The target state may depend on the application querying the data, so often materialized views are created for applications.

• Applications query the views to get the information they need. This can be cached or snapshots may be used in event stores to help with performance at larger scales.

• As you see in the visual, the analytics platform and web application both have different requirements and state to display. They talk to different views to get this information, all derived from the event log.

• Common pattern for this is CQRS (Command and Query Responsibility Segregation)

Audit and trace

• As events are stored, it opens up possibilities for auditing and traceability.

• Depending on your use case event sourcing can be a great pattern to help if you need to get an audit log of certain events within your architecture.

• As the events are stored and materialized views can be used to query the events, various teams can read the data.

• An example could be developer teams may want to replay events helping debug systems, compliance teams may use events for reports or product owners may want a new feature that allows users to see historic transactions within their banking account.

Extra Resources

• Martin Fowler gives us an overview with examples of Event Sourcing - Back in 2005 Martin Fowler released this post still relevant today. He gives us an overview of Event Sourcing with various examples. Great if you want to dive deeper.

• Beginner’s Guide to Event Sourcing - Great guide to dive deeper into Event Sourcing, CQRS, Domain-Driven Design, and much more.

• Microservice Pattern: Event Sourcing - Great website to learn more about Microservice patterns, here is one about Event Sourcing, just in case you still need to learn more!

• What goes into your events? - So you want to try Event Sourcing? But what do you put into your events? Here is a visual I created to help you understand what goes into your events, with something I like to call event-first thinking.

• Commands vs Events? Why do you need to know? - Super relevant for Event Sourcing. There is a difference between commands and events. What are they? Why does it matter? This visual can help you understand more.

• Understanding Eventual Consistency - So you raise events, store them and want to read them. Reading this information will be eventual consistent. What does that mean? Here is a visual to dive deeper and help you understand.