Download as PDF, PPTX
Uploaded byMichael Plöd
Building Microservices with Event Sourcing and CQRS
This document summarizes a presentation about building microservices with event sourcing and CQRS. It begins by reviewing the characteristics of a traditional n-tier architecture, then introduces event sourcing as an architectural pattern where application state is determined by a sequence of immutable events. Key aspects of event sourcing include storing events in an event store, processing events with handlers, and replaying events to rebuild state. CQRS is also introduced, which separates commands from queries by using different interfaces and models. Consistency challenges with event sourcing architectures are discussed, such as eventual consistency, validation, and handling parallel updates.
More Related Content
Similar to Building Microservices with Event Sourcing and CQRS
![20260201 [FOSDEM] gomodjail - library sandboxing for Go modules.pdf](https://cdn.slidesharecdn.com/ss_thumbnails/20260201fosdemgomodjail-librarysandboxingforgomodules-260201225659-76609ec4-thumbnail.jpg?width=640&height=640&fit=bounds)
![谷歌留痕技术教程[ 𝙩𝙤𝙥 𝟮𝟯𝟯. 𝙘 𝙤𝙢 ]](https://cdn.slidesharecdn.com/ss_thumbnails/top233-260130173900-2eb784f9-thumbnail.jpg?width=640&height=640&fit=bounds)
Building Microservices with Event Sourcing and CQRS
- 1. Unless otherwise indicated,these slides are © 2013-2015 Pivotal Software, Inc. and licensed under a Creative Commons Attribution-NonCommercial license: http://creativecommons.org/licenses/by-nc/3.0/ SPRINGONE2GX WASHINGTON, DC Building Microservices with Event Sourcing and CQRS Michael Ploed - innoQ @bitboss
- 2.
- 3.
- 4. 1 We read andwrite data through the same layers IncidentSOAPEndpoint IncidentBusinessService IncidentDAO Incident Business Model Client Incident DTO Incident View Model RDBMS Incident ER-Model Network Network READ WRITE
- 5. 2 We use thesame model for read and write access IncidentSOAPEndpoint IncidentBusinessService IncidentDAO Incident Business Model Client Incident DTO Incident View Model RDBMS Incident ER-Model Network Network
- 6. 3 We use coarsegrained deployment units that combine read and write code IncidentSOAPEndpoint IncidentBusinessService IncidentDAO Client RDBMS
- 7. 4 We change datasets directly IncidentRestController IncidentBusinessService IncidentDAO Incident IDUSER_ID DATE TEXT 1 23423 11.03.2014 Mouse is broken 2 67454 12.03.2014 EMail not working 3 93729 12.03.2014 Office license … … … …
- 8. We’ve done that forages already and it’s proven
- 9. Many applications will runsmooth and fine with this kind of approach
- 10. However there are drawbacksto this kind of architecture
- 11. 1 The datamodel is a compromise 2 You can’t scale read and write independently 3 No data history, no snapshots, no replay 4 Tendency to a monolithic approach
- 12. Event Sourcing isan architectural pattern in which the state of the application is being determined by a sequence of events
- 13. Building Blocks Applications Event Queue Applications issues eventsto a queue Event Handler Event Store Events are stored in the event store The Event handler is processing the events
- 14. The sequence ofevents in the queue is called event stream t now EventEventEventEventEvent
- 15. IncidentCreatedEvent incidentNumber: 1 userNumber: 23423 timestamp:11.03.2014 12:23:23 text: „Mouse broken“ status: „open“ Event Stream Example IncidentTextChangedEvent incidentNumber: 1 text: „Left button of mouse broken“ IncidentClosedEvent incidentNumber: 1 solution: „Mouse replaced“ status: „closed“
- 16. An event issomething that happened in the past t now EventEventEventEventEvent
- 17. The names ofthe events are part of the Ubiquitous Language D D D
- 18.
- 19. 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(); } }
- 20. Scope your eventsbased on Aggregates D D D
- 21. An Event isalways immutable !
- 22. There is nodeletion of events !
- 23. A delete is justanother event IncidentCreatedEvent incidentNumber: 1 userNumber: 23423 timestamp: 11.03.2014 12:23:23 text: „Mouse is broken defekt“ status: „open“ IncidentChangedEvent incidentNumber: 1 text: „Maus ist Kaputt“ IncidentRemovedEvent incidentNumber: 1
- 24. The event busis usually implemented by a message broker t now EventEventEventEventEvent
- 25. Let’s reuse theESB from the failed SOA project
- 26.
- 27.
- 28.
- 29. ! Prefer dumb pipes withsmart endpoints as a suitable message broker architecture
- 30. 1 Complete rebuildis possible 2 Temporal Queries 3 Event Replay
- 31. Well known examples = VersionControl Systems or Database Transaction Logs
- 32. The Event Store hasa very high business value
- 33. Aren’t there performance issuesattached to this kind of data storage?
- 34.
- 35. Application State Think about applicationstate Application Event Queue Event Handler Event Store Application State The application queries the pre-processed application state
- 36.
- 37.
- 38.
- 39.
- 40.
- 41. Classic Interface public interfaceIncidentManagementService { Incident saveIncident(Incident i); void updateIncident(Incident i); List<Incident> retrieveBySeverity(Severity s); Incident retriveById(Long id); }
- 42. CQRS-ified Interfaces public interfaceIncidentManagementQueryService { List<Incident> retrieveBySeverity(Severity s); Incident retriveById(Long id); } public interface IncidentManagementCommandService { Incident saveIncident(Incident i); void updateIncident(Incident i); }
- 43. Event Store EventHandler EventsEvents EventSourcing & CQRS IncidentCommandEndpoint IncidentCommandService IncidentCommandDAO IncidentQueryEndpoint IncidentQueryService IncidentQueryDAO Read Storage Events READ
- 44. 1 Individual scalabilityand deployment options 2 Technological freedom of choice for command, query and event handler code 3 Excellent Fit for Bounded Context (Domain Driven Design)
- 45. Event Sourcing andCQRS are interesting architectural options. However there are various challanges, that have to be taken care of
- 46. 1 Consistency 2 Validation 3Parallel Updates
- 47.
- 48. ! Systems based on CQRSand Event Sourcing are mostly eventually consistent
- 49. Event Store EventHandler EventsEvents EventualConsistency IncidentCommandEndpoint IncidentCommandService IncidentCommandDAO IncidentQueryEndpoint IncidentQueryService IncidentQueryDAO Read Storage Events READ
- 50.
- 51. ! You can builda fully consistent system which follows Event Sourcing principles
- 52.
- 53. Your business domaindrives the level of consistency not technology Deeper Insight D D D
- 54. Increased (but stilleventual) consistency EventHandler EventsEvents IncidentCommandEndpoint IncidentCommandService IncidentCommandDAO IncidentQueryEndpoint IncidentQueryService IncidentQueryDAO Read Storage Events Select * from Event Store async
- 55. ! There isno standard solution
- 56. 1 Consistency 2 Validation 3Parallel Updates
- 57. 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
- 58. We process 2 million+registrations per day. A user can change her email address. However the emails address must be unique
- 59. ? How high isthe probability that a validation fails Which data is required for the validation Where is the required data stored
- 60. $ What is thebusiness impact of a failed validation that is not recognized due to eventual consistency and how high is the probability of failure
- 61. Your business domaindrives the level of consistency Deeper Insight D D D
- 62. 1 Validate fromEvent Store 2 Validate from Read Store 3 Perform Validation in Event Handler
- 63. Never validate from theevent store
- 64. 1 Consistency 2 Validation 3Parallel Updates
- 65. 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
- 66. What happens whenAlice and Bob share an account and both update the email address at the same time
- 67. ? What would wedo in a „classic old school architecture“
- 68. UserRestController UserBusinessService UserDAO User ID EMAIL PASSWORD …… … 2341 alice_bob@xyz.com lksjdaslkdjas … … … Update Pessimistic or optimistic locking
- 69. Your business domaindrives the locking quality Deeper Insight D D D
- 70. ! Pessimistic locking on a data-levelwill hardly work in event sourcing architectures
- 71. EventHandler EventsEvents Where to„pessimistically“ lock? Read Storage Events Event Store UserRestController UserBusinessService UserDAO User Commands Consider a business lock with a UserLockedEvent
- 72. ? Do you REALLY need afull lock Most „classic architecture“ applications are already running fine with optimistic locks
- 73. 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
- 74. 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
- 75. Also here: you shouldbe as consistent as your domain requires
- 76. Unless otherwise indicated,these slides are © 2013-2015 Pivotal Software, Inc. and licensed under a Creative Commons Attribution-NonCommercial license: http://creativecommons.org/licenses/by-nc/3.0/ SPRINGONE2GX WASHINGTON, DC Thank You! Michael Ploed - innoQ Twitter: @bitboss Slides: http://slideshare.net/mploed