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...): 🤓
https://marcolenzo.eu/

🤝 Connect with me: 🤝
  / marcolenzo  

👌Get a CodeCrafter Discount 👌
https://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 Microservices | Whi...  
   • OVERLOOKED Challenges of API-Based Mi...  

#eventdrivenarchitecture #cqrs #microservices #softwarearchitecture