Event Sourcing and CQRS Explained | When should you use them?

Event Sourcing and CQRS are possibly the most fascinating architectural patterns in the software world, especially when combined with an event-driven architecture (EDA). In contrast to traditional applications that store exclusively the current state of the system while losing the history of all operations and changes applied to it, event sourcing dictates that all state changes have to be represented as events and persisted an append-event only log. The state of the system is sourced from such events through a process called hydration.

Auditing and the ability of replay the history of events to hydrate new versions of our model are some of the incredible benefits this patterns give us. However, the challenges are equivalently important.

In this video, we will try to reach a conclusion and establish whether we should these patterns use in our system.

A lot of inspiration has been taken by articles and presentations by Greg Young and Martin Fowler.

🤓 There's more on my website! (articles, scripts, code snippets, etc...): 🤓

🤝 Connect with me: 🤝

👌Get a CodeCrafter Discount 👌

🍕 *I've got an Italian accent* 😅
If you have trouble understanding me, activate the closed captions! They are manually corrected.

00:00 Event Sourcing
03:57 CQRS
05:12 Benefits
07:40 Drawbacks
11:01 Conclusion

Other interesting videos related to Event Driven Architectures:

#eventdrivenarchitecture #cqrs #microservices #softwarearchitecture

[MarcoLenzo]

Do you have experience with event sourcing and CQRS? Would you recommended it to a fresh software development team? Let us know! 🤓🤓🤓

[stanislavstudzinskyi]

Priceless. Thank you so much, Marco, for your efforts

[marcelobalbuena]

Good short and still comprehensive summary of this pattern. I will definitely consider your pros and cons in our architecture. Thanks Marco!

[LawZist]

I very much agree with your conclusion! In my company I’m working at, we use event sourcing only for audit and investigation purposes as you mentioned. We still keep records in the “traditional” crud way (we don’t build current state from event sourcing )

[josedonato]

Thank you Marco, great video as always

[uchchhash-dev]

Great video. Thanks for the precise explanation!!

[kvieres]

Really god information.. totally agree with your conclusion...

[omidh]

Thanks, Marco. The concepts are mentioned clearly and deftly. ✌

[jwbonnett]

CQRS can also be strong consistancy, it depends on the architecture of the app, for instance, only replying in the event of completing the data projection write. It can also be done with little delay, pretty much inconceivable to the user and has little effect on the system.

It is also not forbidden to modify an event, it's just not recommended due to increased complexity and time burden as it can have a ripple effect for any event that comes after.

I would actually recommend using event sourcing, simply due to the fact that you can trade complexity from other things, like database design for new services and features. This is because it is a 100% code first approach. It also matches more closely to a business process, meaning process to code is a lot more simple as you just copy the process rules and can't be accused of not following the business rules.

[ClaytonTaboneMT]

Another great video! Great and concise explainer on Event Sourcing and CQRS, with a sprinkle of Magic Architecture Dust 😂