what if we stored events instead of state?
DESCRIPTION
Traditional systems typically only store the current state. This paradigm often puts us in rather nasty situations. How do you optimize for reads, without impacting writes? How can you have a clue of what's going in your system? How do you reproduce bugs..? Learn how event sourced systems address these concerns by, instead of storing the current state, storing the sequence of events that lead to the current state - unleashing a bunch of scenarios impossible using traditional systems.TRANSCRIPT
WHAT IF WE STORED EVENTS INSTEAD OF STATE?
SCENARIO’S• The user can put up a card. • The user can move the card to the doing section. • …
COMMANDS• Put up a card. • Move card to doing section. • …
State + Behavior
Traditional systems store current state.
We have no idea what has happened in our system.
Audit logs anyone?
State Audit log
Deposit 500 € 500 €
Deposit 200 € 700 €
Withdraw 300 € 400 €
Deposit 1000 € 1400 €
Withdraw 400 € 1000 €
Withdraw 200 € 800 €
… …
Deposit 500 € Deposited 500 € 500 €
Deposit 200 € Deposited 200 € 700 €
Withdraw 300 € Withdrawn 300 € 400 €
Deposit 300 € Deposited 1000 € 1400 €
Withdraw 400 € Withdrawn 400 € 1000 €
Withdraw 200 € Withdrawn 200 € 800 €
… …
Command - Event - State
Something that happened - past tense.
Store the sequence of events that led up to the current state, instead of the current state.
Command State
Put up a new card“Reset Password”
Card“Reset Password”
“Todo”
Move card to doingCard
“Reset Password”“Doing”
… …
Command Event State
Put up a new card“Reset Password”
Card put up“Reset Password”
“Todo”
Card“Reset Password”
“Todo”
Move card to doing Moved card to section “Doing”
Card“Reset Password”
“Doing”
… … …
An event store
EventId StreamId Type Payload MetaData
1 card/1 CardPutUp { … } { … }
2 card/1 MovedCard ToSection { … } { … }
3 card/1 MovedCardToSection { … } { … }
… … … …
You can’t undo the past.
Append-only.
Forever cacheable.
What about queries?
Model
Writes Reads
Write model
Writes
Write model
Writes
Read model
Reads
Write model
Writes
Read model
Reads
Events
We can build a read model from events committed to the write model.
Events Dispatcher Projection Read model
Events Dispatcher Projection Read model
Projection Read model
Events Dispatcher Projection Read model
Projection Read model
Projection Read model
We can build read models from events committed to the write model.
More than one way to look at your data.
BehaviorSearch
ReportingViews
…
ComplexSlow
Fragile
What if I mess up my read models?What if I need to update my read models?
What if I need a new read model?
Temporal queries.
Tell me which day most work gets done.
Monday Tuesday Wednesday …
CardMovedCardMovedCardMovedCardMovedCardMoved
CardMovedCardMoved
CardMovedCardMovedCardMoved
Not just for read models and queries.
Events Dispatcher Projection Read model
Projection Read model
Projection Read model
Integration
Pub-Sub
Events Dispatcher
Projection
Projection
Projection
Transaction
Events Dispatcher
Projection
Projection
Projection
Events
Projection
Projection
Projection
Events Dispatcher (Queue)
Projection (Queue)
Projection (Queue)
Projection (Queue)
When?
When you can’t afford to lose data.
Business Intelligence Auditing
Reproducing issues Challenging/changing business models
Decouple reads from writes
Conceptual puritySimplicity (no monolith)
Polyglot persistancePerformance
High availability
Integration with other systemsTesting
…
No silver bullet
In conclusion
Event sourcing, for when the what and the when are important.
… but really, it’s a lot more than that.
Experiment!
http://neventstore.org/http://geteventstore.com/
https://groups.google.com/forum/#!forum/dddcqrs
@gregyoung
@abdullin
@randompunter
@jonathan_oliver
@jen20
@yreynhout @mathiasverraes
@thinkb4coding@eulerfx
@ziobrando
@tojans
