Building Event-Driven Microservices with Event Sourcing and CQRS - Lidan Hifi
Vložit
- čas přidán 22. 07. 2024
- Most systems today store only the current state of their business entities.
However, you can look at the current state through a different lens, as a derivative of previous behaviors. Storing past behaviors as a sequence of events, instead of the current state of the entity, will gain you accurate audit logging, history revisions, flexible schemas and more. The current state is derived by replaying the events.
Event Sourcing is a great way to implement event-driven applications, and it’s often combined with CQRS (Command Query Responsibility Segregation) which is a key part of an architecture that is based on event sourcing.
In this talk, Lidan will cover the principles of Event Sourcing pattern, how to model your data accordingly and how you can improve your system by segregating reads and writes using specialized read models.
You’ll learn how these concepts fit in with event-driven microservices through a real-life example - an invoice management app we built at Wix.
NDC Conferences
ndcoslo.com
ndcconferences.com - Věda a technologie
Eventsourcing and CQRS is also a source of accidential complexity. Suddenly you need to have a separate read model and write model. Instead of a database transaction you now have a distributed transaction which needs a process manager (saga). You introduce dependencies on a message bus and possibly also on a message scheduler.
And you introduce eventual consistency which you need to consider when applying commamds and querying.
Everything is already eventually consistent, work with it, not against it.
This is probably one of the best talks on event sourcing that I've ever seen. It tackles even the stuff that aren't even touched upon on other ES+CQRS talks!
Really great talk! I learned a lot!
Great presentation! I learned many things, thank you!
Somebody seems to have watched as much Greg Young as I have. It's nice seeing these ideas as applied by someone working in web rather than more enterprise business software though.
I agree. I hear so many well known phrases and sentences. Even overall talk pattern feels so familiar. :) But i liked some of the slides.
Indeed, this was a bad ripoff of any of Greg Young's talks.
Really great explanation. Learned a lot from this.
Anyone know any practical code sample for event sourcing, its seem to me that all videos for event sourcing and CQRS is conceptual rather than practical, even Greg Young videos
logcorner.com/building-microservices-through-event-driven-architecture-part7-event-sourcing-core-domain/
This is a must watch for anyone starting with event sourcing and CQRS pattern for microservices... kind of saved my a** in an interview discussion as well 🙌🙌
Thank you Lidan. what kind of data base options are available for storing all the events?
Cannot fully agree that consistency model is a business concern. In some cases it definitely is - how to reach consensus or convergence when multiple users send concurrent commands? In other cases, it's a technical problem - business always wants strong consistency, but we have to sacrifice by relaxing guarantees to get better performance/availability.
Regarding locking, why not to just use kafka with custom partitioner per each aggregate ?
it makes it harder to scale, the actor model pattern is a better fit.
Can we also get the practical examples?
Can you please share some sample application code
where is the building part ?
Yet another, introduction into boxes, arrows and other powerpoint shapes.
Sounds great on paper. But I can think of some cases where this will become a nightmare. 1. How do you build complex views that might involve changing business requirements? Do you have to replay all the events from the beginning of time? 2. How do you maintain business rules versioning? I assume events and event sequences will change when business rules changes. How do you replay the events with the correct version of business rules? 3. How do you coordinate transactions when all the events are async?
You should replay all the events when your views change, yes. If you have millions of events, your best bet is to have a new view and keep the old one until the newer one is in sync.
Somehow, you need to keep in mind these business rule changes. That entirely depends on the business rules and the changes, though...
You don't need to coordinate the transactions, just define your events and sagas correctly
Thanks
Can you please upload a sample application preferably in asp.net core covering these concepts. That would be great
Can you please take the poo to the loo. That would be great
@@salvatoreshiggerino6810 he is probably a beginner.. no need to be rude dude..
*loud tongue smack" this was very helpful, thank you for the clear and thorough presentation!
Good quality introduction talk for devs new to event sourcing. The speaker clearing his throat constantly is very distracting unfortunately.
everything can be event sourced. it's basic accounting. if you fail, it's a skill issue lmao
Too simplistic
Too high level - that's plus and minus too. Good for understanding the principle but do not show real ways of pitfalls.
Not a very good talk unfortunately. Learn the concept from another source if you want a more quality content.
Why is that?
Ok but a few too many misleading statements
there is nothing called -Accidental Complexity.
you do lot of brain storming then you design architecture, then you code it for months.
now if that fails, it's not an ACCIDENT, it is inexperienced.