Event Sourcing

About a year ago, I started to work with event sourcing and built a system around it. It seemed quite new to me, but the more I learned, the easier it became. Basically, I've already worked with event sourcing pattern for my entire career as a software engineer even starting at school, however, I didn't realise it at that time.

A good example we use every day

As long as you have coding experience you should be able to work with version control systems such as Git, which is a good example of event sourcing pattern. Every commit you push to Git is stored as an event representing a change state that can be added, edited or removed from files or code. This is the core concept of event sourcing where you can source back all the events that have happened in the past. As a result of this, we can revert the changes that have been made in the code from git whenever needed - Just like a time machine isn’t it ;)

The sooner you master Git the quicker it makes your life easier. It had my back a few times in my career and saved a lot of time :) I highly recommend git to those who want to work as a developer and spend some time cultivating it. I digress a little bit here. Let's talk about when to use event sourcing. It’s not a silver bullet that allows you to solve any problem, it really does add complexity to your system, so make sure you think through the goal you want to achieve that can be solved by it before adopting it.

Audit trails

The first scenario where you might use event sourcing is when you want full audit trails in your system, like in payment or banking. This is also the main reason why I use it in my work. We have various records and transactions including financial, accounting and medical that need to be tracked and verified.

Reporting

The second is reporting. With event sourcing you have much more insight into your data and you can report retrospectively. Just like data mining, where you extract meaningful information from a collection of data.

Parallel processing

The third scenario is parallel processing. Each microservice communicates via event messages, so they are loosely coupled without interdependence. Suppose you are looking for a highly scalable solution, this could potentially satisfy horizontal scalability and resilience to system failures.

Summary

We have gone through some use cases can be resolved by event sourcing such as audit trails, reporting or parallel processing. Are there other problems that can be solved with event sourcing? Tell me what you think and I hope this blog inspires you to explore solutions for your use cases.

Some thoughts on using Event Sourcing

Comments

More from this blog

Go Slice Copying: What Really Happens Under the Hood?

AI Technology Meets Social Media: The Discord Bot Project

One Thing You Might Overlook When Reading Response Body in Go

Unleashing the power of Go: How to Unmarshal Dynamic JSON

Tips on How to Speed Up Your Workflow

A good example we use every day

Audit trails

Reporting

Parallel processing

Summary

Command Palette

Comments

More from this blog

A good example we use every day

Audit trails

Reporting

Parallel processing

Summary