Download as PDF, PPTX
Uploaded byMichael Plöd
Event Sourcing: Introduction & Challenges
The document discusses event sourcing as an architectural pattern, emphasizing its ability to track state changes through a sequence of events rather than just storing the current state of applications. It highlights the advantages and challenges of implementing event sourcing and CQRS, including issues related to consistency, validation, and parallel updates. The author argues for the importance of aligning implementation with business domain needs and notes the necessity of careful consideration in managing application state and event storage.
In this document
Powered by AI
Introduction to Event Sourcing and its complexities provided by Michael Plöd.
Highlights how current systems only store the current state, leading to limitations in history tracking.
Discusses the qualities of reactive systems: responsive, resilient, elastic, and message-driven.
Introduction to Event Sourcing as an architectural pattern and the importance of event immutability.
Elaboration on events like IncidentCreated, IncidentChanged, and IncidentClosed; everything is an event.
Acknowledges performance issues tied to Event Sourcing data storage and emphasizes application state.
Introduction to Command Query Responsibility Segregation (CQRS) and its relationship with Event Sourcing.
Discusses challenges around consistency in Event Sourcing and the possibility of achieving full consistency.
Explores various consistency-related issues in the context of user registrations and email changes.
Addresses the problems arising from concurrent updates and the potential of optimistic locking solutions.
Final thanks and contact details provided by Michael Plöd.
More Related Content
Similar to Event Sourcing: Introduction & Challenges
Event Sourcing: Introduction & Challenges
- 1. Event SourcingIntro &Challenges
- 2.
- 3. Most current systems onlystore the current state
- 4. IncidentRestController IncidentBusinessService IncidentDAO Incident ID USER_ID DATETEXT 1 23423 11.03.2014 Maus defekt 2 67454 12.03.2014 EMail Empfang 3 93729 12.03.2014 Monitor defekt … … … … Classical Architecture
- 5. IncidentRestController IncidentBusinessService IncidentDAO Incident ID USER_ID DATETEXT 1 23423 11.03.2014 Maus ist kaputt 2 67454 12.03.2014 EMail Empfang 3 93729 12.03.2014 Monitor defekt … … … … Update The dataset is directly being changed, no history
- 6. 1 Audit Logonly with extra effort 2 No replay 3 Snapshots only with extra effort or via backups
- 7.
- 8. Many applications are workingwell with the classic approach
- 9. However there areareas where this approach reaches it’s limitations
- 10.
- 11. ? Responsive ? Resilient ?Elastic ? Message driven
- 12.
- 13. Event Sourcing isan architectural pattern in which the state of the application is being determined by a sequence of events
- 14. Building Blocks Applications Event Queue Applications issues eventsto a queue Event Handler The Event handler is processing the events Event Store The event store is persisting the events
- 15. An event issomething that happened in the past t jetzt EventEventEventEventEvent
- 16. The names ofthe Events are part of the Ubiquitous Language D D D
- 17.
- 18. Code Example public classCustomerVerifiedEvent { private String eventId; private Date eventDate; private CustomerNumber customerNumber; private String comment; public CustomerVerifiedEvent(CustomerNumber custNum, String comment) { this.customerNumber = cusNum; this.comment = comment; this.eventDate = new Date(); } }
- 19. Scope your eventson the basis of Aggregates D D D
- 20. An Event isalways immutable !
- 21. The sequence ofevents in the queue is also called Event Stream tnow EventEventEventEventEvent
- 22. IncidentCreatedEvent incidentNumber: 1 userNumber: 23423 timestamp:11.03.2014 12:23:23 text: „Maus defekt“ status: „offen“ Event Stream Example IncidentTextChangedEvent incidentNumber: 1 text: „Maus ist Kaputt“ IncidentClosedEvent incidentNumber: 1 solution: „Neue Maus“ status: „geschlossen“
- 23. Let’s reuse theESB from the failed SOA project
- 24.
- 25.
- 26.
- 27. ! Prefer dumb pipes withsmart endpoints as a suitable message broker architecture
- 28. 1 Complete rebuildis possible 2 Temporal Queries 3 Event Replay
- 29. Well known examples = VersionControl Systems or Database Transaction Logs
- 30. The Event Store hasa very high business value
- 31. There is nodelete! !
- 32. A delete is justanother event IncidentCreatedEvent incidentNumber: 1 userNumber: 23423 timestamp: 11.03.2014 12:23:23 text: „Maus defekt“ status: „offen“ IncidentChangedEvent incidentNumber: 1 text: „Maus ist Kaputt“ IncidentClosedEvent incidentNumber: 1 solution: „Neue Maus“ status: „geschlossen“ IncidentRemovedEvent incidentNumber: 1
- 33. Aren’t there performance issuesattached to this kind of data storage?
- 34.
- 35. Application State Think about applciation state Application Event Queue Event Handler Event Store Application State Theapplication queries the pre-processed application state
- 36.
- 37.
- 38.
- 39. EventHandler EventsEvents Event Sourcing& CQRS IncidentCommandEndpoint IncidentCommandService IncidentCommandDAO IncidentQueryEndpoint IncidentQueryService IncidentQueryDAO Read Storage Events Select * from Event Store
- 40. Event Sourcing isan interesting architectural option. However there are various challanges, that have to be taken care of
- 41. 1 Consistency 2 Validation 3Parallel Updates
- 42.
- 43. ! Systems based on CQRSand Event Sourcing are mostly eventually consistent
- 44.
- 45.
- 46. ! You can builda fully consistent system which follows Event Sourcing principles
- 47.
- 48. Your business domaindrives the level of consistency not technology Deeper Insight D D D
- 49. Increased (but still eventual)consistency EventHandler EventsEvents IncidentCommandEndpoint IncidentCommandService IncidentCommandDAO IncidentQueryEndpoint IncidentQueryService IncidentQueryDAO Read Storage Events Select * from Event Store async
- 50. ! There isno standard solution
- 51. 1 Consistency 2 Validation 3Parallel Updates
- 52. Example Domain User Guid id Stringemail String password RegisterUserCommand ChangeEmailCommand UserRegisteredEvent Guid id Date timestamp String email String password EmailChangedEvent Guid userId Date timestamp String email
- 53. We process 2million+ registrations per day. A user can change her email address. However the emails address must be unique
- 54. ? How high isthe probability that a validation fails Which data is required for the validation Where is the required data stored
- 55. $ What is thebusiness impact of a failed validation that is not recognized due to eventual consistency and how high is the probability of failure
- 56. Your business domaindrives the level of consistency Deeper Insight D D D
- 57. 1 Validate fromEvent Store 2 Validate from Read Store 3 Perform Validation in Event Handler
- 58.
- 59. 1 Consistency 2 Validation 3Parallel Updates
- 60. Example Domain User Guid id Stringemail String password RegisterUserCommand ChangeEmailCommand UserRegisteredEvent Guid id Date timestamp String email String password EmailChangedEvent Guid userId Date timestamp String email
- 61. What happens when Aliceand Bob share an account and both update the email address at the same time
- 62. ? What would wedo in a „classic old school architecture“
- 63. UserRestController UserBusinessService UserDAO User ID EMAIL PASSWORD …… … 2341 alice_bob@xyz.com lksjdaslkdjas … … … Update Pessimistic or optimistic locking
- 64. Your business domaindrives the locking quality Deeper Insight D D D
- 65. ! Pessimistic locking on a data-levelwill hardly work in event sourcing architectures
- 66. EventHandler EventsEvents Where to „pessimistically“lock? Read Storage Events Event Store UserRestController UserBusinessService UserDAO User Commands Consider a business lock with a UserLockedEvent
- 67. ? Do you REALLY need afull lock Most „classic architecture“ applications are already running fine with optimistic locks
- 68. Introduce a versionfield for the domain entity User Guid id Long version String email String password RegisterUserCommand ChangeEmailCommand UserRegisteredEvent Guid id Date timestamp String email String password EmailChangedEvent Guid userId Date timestamp String email Long version
- 69. Each writing event increasesthe version UserRegisteredEvent {guid: 12, version: 0, email: alicebob@xyz.com, password: werwe2343} EmailChangedEvent version: 0 EmailChangedEvent version: 1 EmailChangedEvent version: 1 {guid: 12, version: 1, email: alice_bob@xyz.com, password: werwe2343} {guid: 12, version: 2, email: alice@xyz.com, password: werwe2343} EmailChangeFailedEvent
- 70. Also here: you shouldbe as consistent as your domain requires
- 71.