Introduce yourself 1 year with CQRS and Event Sourcing Passion about CQRS
I will guide you through the evolution of our software. Because to me, CQRS is the natural evolution step in enterprise software development.
Ask questions you might forget Give feedback Vote in the poll Get the presentation
Document management system – Monolith Client wanted a workflow engine Execute business processes over documents Storing a document triggers a workflow (INSTANCES) Indexing is applied Users get tasks Users confirm decisions Workflow ends
Q: How many monoliths here?
A trivial CRUD system Instances are created Tasks deleted after confirmation Instances are deleted after finish Small DB = Fast requests Client wanted History Missing History We could do one thing
Great developers Did it by the books PO had to think of this
Stop deleting anything Add state column Get History from here Client wants History of automatic steps Missing
1. PO is to blame again
Added History tables Move from active to History Data = Text for UI Customer got a corrupted workflow. Asked to restore it from history Can’t, history is only for UI
Getting in the cloud GetTasks – SLOW MANY LOCKS History – UNUPGRADEABLE Scaling – Not very efficient
Q: Anyone had such problems? Q: How did you solve it?
Colleague said CQRS is awesome Skeptic at first Many discussions Changing architecture is hard But first – WHAT IS CQRS? It is not scary!
OK, it is scary! That makes you cringe Let’s simplify
Not so scary now Makes sense WHY do we need that? Did a research We read more than we write
Our logs show that
Q: Have you done such a check? Q: What does it show?
11 TIMES MORE
Started thinking about separation How do you separate your model? Makes a lot of sense Many things – not used in both Colleague afraid to have much data in table Told him because he haven’t split
Read site (query model) Queries return data Write side (command model) Commands mutate state Separated Async – Not mandatory But preferable
Scale Read & Write independently Read side denormalized Read side straightforward Write side is not UI dependent Model separation is meaningful Scales better
CAP Theorem Eric Brewer 1998 You need to duplicate data in models quite often
State is stored as a series of events Append only store Compares to transactional log of DB Entities are called Aggregates
Start by initial instance Apply events one by one Each event changes specific properties Idempotent events Applied events go to Projections (ReadModels) Auditing
Concerned about size How to iterate millions of events
If you use SQL – it is FAST Good PK = FAST EventStore NoSQL Snapshotting = aggregate state every 5-10 events Small DB footprint with Google Protobuf At time of choice – best serialization
Made Get tasks faster Most important about client Confirms are async in the background How fast?
Can you guess how much A LOT, PEOPLE!
Independently scale Split models = clear models GetTasks got a lot faster Create Read Models Easy Auditing! Fancy words on our resume and site That was a joke…