I may start using Event Sourcing in all my Laravel applications

Event sourcing is more of a fancy term which I first saw in the Laracon talk by Dries Vints. It was a half-an-hour-long video. I saw something interesting about the term and let it play in the background while I pretended to work on my tasks.

The first example was a banking application. It kept history, and the aggregated value was used to show the current balance. Halfway through the video, I paused and thought, ‘If we’re just keeping history, why do I need another dependency?’

Last week, Nuno Maduro, one of the Laravel creators took on the challenge of learning Event Sourcing during his Live stream. It was the second time I heard the term. And let’s face it, you don’t miss Nuno’s stream.

He was diving into the documentation and implementing the process in one of the universally hardest projects, a “TODO” application.

After watching the video, YouTube read my mind and suggested a video by Chris Morrell, one of the creators of Verbs, where he rewrote Nuno’s “TODO” application. He built the application by showing how it should be done using Event Sourcing.

Chris’s approach got me hooked and I, keeping all my important work aside, started learning Event Sourcing. Laracon talks by Daniel Coulbourne, another creator of Verbs, were fun and engaging which helped me understand the concept of Event Sourcing.

If you are new to the concept or have experience in Event Sourcing, you will either learn something new or can correct my understanding of the pattern.

Event Sourcing

Event sourcing is an architectural pattern. It logs the events in chronological order instead of simply storing the current state of an entity. By storing in chronological order, it provides a complete history of how the state evolved and can act as a “source of truth”.

In the traditional approach, databases are used to store the current state. During every action upon the state, the final result is stored in the database. However, in event sourcing, all the actions are stored in the append-only log as an immutable record.

This historical record can be replayed to reconstruct the current state, providing insights into every change that took place and ensuring that nothing is lost. It’s especially valuable in systems where tracking changes over time is crucial.

Why Event Sourcing?

Event sourcing is like a CCTV camera for every action in your application. Each action or change can be stored as an event, much like how a camera captures every moment of an activity.

• Everything is documented in the events themselves.
• Storing every event in chronological order allows us to have a full audit trail of what happened. The current state will have a trace of every action that led to it, providing a comprehensive understanding of its evolution.
• Any error in the current state can be fixed by updating the source of the error and replaying the events. This makes debugging and recovery much easier since you don’t need to track down how the error was introduced in the current state.
• Since events are appended to an immutable log and never overwritten, it ensures that no data is lost. A higher level of reliability and data integrity can be achieved compared to systems that rely solely on the current state.
• Highly scalable. Event Sourcing makes your system more flexible and efficient as it grows, allowing you to manage and scale it without adding complexity.

How I Fell in Love with Event Sourcing

It all started with the videos I saw on YouTube. However, I first used the pattern in an e-commerce application. Managing product inventory was not too hard a job but I saw an application of event sourcing while handling the product’s current quantity.

While I was trying event sourcing, I used Verbs. Feel free to check the package.

To start, I created some basic events like StockAdded, ProductPurchased, and StockAdjusted. Each time something happened, I fired an event. The ProductState state handled the quantity, and everything just magically worked.

But the state isn’t something we can use in user-end. This increased the database queries which may later result in a less-performant system. So, I added the quantity column in the products table.

Then I updated the event’s handling logic to update the database with the state’s value and saw the real use of replaying the event. The quantity column had a number as if it was already included earlier.

With this simple application, I got the gist of how event sourcing can time travel and change the past.

Should You Use Event Sourcing for Everything?

I admit that event-sourcing is not for every project. If you are building a simple application where 2 people can come and comment on the blog post, then having any event on each action doesn't make sense. For small-scale applications, event sourcing is an overkill; this will add unnecessary complexity.

But what if your blog website booms and you want to reward users and add an experience point to every comment? Traditionally you would say, “From now on, we are giving points for every comment”.

But what if your users want points for their previous comments? You will be writing a script for every previous comment and assigning points manually. You’d be digging through data and performing updates one by one, which is not only time-consuming but error-prone.

This is where event sourcing shines. By using event sourcing from the beginning, you store each action as an event. For instance, you’d have an event like UserCommented that records the user, the comment, and the time it was posted.

With this historical data in your event store, you can easily apply your new logic (rewarding points for comments) to all past comments by simply replaying the events.

Event sourcing allows your application to scale with ease and adapt to new features without significant rework. So, if your application is likely to evolve, or if there’s a chance you’ll need to retroactively apply new rules to data, event sourcing can be incredibly useful.

Downsides of Event Sourcing

Within this article, I talked about how event sourcing can be useful for your applications and how it can be an overkill for something that is small and simple. However, there are some of the downsides that you should be aware of before deciding to use event sourcing in your application:

• Instead of just storing the current state, you are storing the events. So, it increases project complexity.
• There is a steep learning curve for someone who doesn’t have the pattern familiarity.
• Event storage logs can grow extremely large over time. Handling a high volume of events may lead to storage and sometimes performance issues.
• Rebuilding the current state, i.e. replaying the events can be a hectic task when you have a large set of events.
• Tracking down the bugs can be complicated when you have a large number of event handlers with a lot of dependencies.

There are even more downsides to event sourcing, which I will add above after I encounter those.

Conclusion

Event sourcing has changed my way of thinking about application design. I may now look for an area where I can inject events. However, I will be careful not to overkill any project because of it.

Since I used Verbs for my Laravel applications, I may write an article about it soon.

Have you ever used event sourcing in your applications? If so, which package do you prefer?