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...): 🤓
marcolenzo.eu/
🤝 Connect with me: 🤝
/ marcolenzo
👌Get a CodeCrafter Discount 👌
app.codecrafters.io/join?via=...
🍕 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:
• APIs vs Events in Micr...
• OVERLOOKED Challenges ...
#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! 🤓🤓🤓

[@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 )

[@MarcoLenzo]

Thank you very much for taking time to give feedback 🙏

[@marcelobalbuena8990]

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

[@MarcoLenzo]

Thank you Marcelo!

[@stanislavstudzinskyi2347]

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

[@MarcoLenzo]

Thank you Stanislav 🙏

[@josedonato9471]

Thank you Marco, great video as always

[@MarcoLenzo]

Thank you Jose! 🙏

[@kvieres]

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

[@MarcoLenzo]

Thank you

[@omidh2007]

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

[@MarcoLenzo]

Thank you! 🙏

[@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.

[@MarcoLenzo]

Thank you very much for the feedback! I do have a question (end of this answer).
I agree that within the same process, it is possible to have strong consistency very easily.
I also agree that you can modify an event. However, I feel you'd be bending the original definition quite a lot since the immutability of events is what gives stronger auditing guarantees compared to other paradigms. If you allowed the event log to be rewritten, it would lose value in that sense. However, it is always a question of what matters the most in your application.
The complexity topic is the bit where I am the most torn. I have read in multiple texts that when modeling events (e.g. in event storming) it is easier to keep a direct mapping with the business rules. I can see that. The bit where I get lost is that in my mind, the complexity is shifted further where we materialize events into projections / model / views. Isn't it typical domain modeling still necessary there?

[@jwbonnett]

@@MarcoLenzo It can be done easily even if it is not in the same process, I do it all the time as it doesn't take enough time to warrent eventual consitancy, it's a little more work, though it is worth it for strong consistancy.
That is why I said that it is not recommended. Just outright saying it is strict is confusing to beginners, in reality it is just best practice.
Projections don't have to be a strict structure, it can still be in the format of a payload, so modeling isn't needed still. This will also mean no mapping to an object before returning. Though I may add you can still map and query quite easily with little overhead, but the point of projections is not to have joins or complex queries due to the overhead they bring.

[@MarcoLenzo]

Understood! Thanks a lot for the insight

[@ClaytonTaboneMT]

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

[@MarcoLenzo]

Lol

[@user-ql1rg9mj9d]

good video

[@MarcoLenzo]

🙇 Thank you