WHAT IF WE STORED EVENTS INSTEAD OF STATE
•
7 gostaram•5,235 visualizações
The document discusses storing a sequence of events instead of state in a system. It proposes an "event store" approach where commands are logged as events and the current state can be reconstructed by replaying the sequence of events from the beginning. This allows an audit log to be maintained and for multiple "read models" to be generated from the event stream to serve different queries or views of the data.
Recomendados
Mais conteúdo relacionado
Semelhante a WHAT IF WE STORED EVENTS INSTEAD OF STATE
Semelhante a WHAT IF WE STORED EVENTS INSTEAD OF STATE (16)
Último
Último (20)
WHAT IF WE STORED EVENTS INSTEAD OF STATE
- 1. WHAT IF WE STORED EVENTS INSTEAD OF STATE?
- 5. SCENARIO’S • The user can put up a card. • The user can move the card to the doing section. • …
- 6. COMMANDS • Put up a card. • Move card to doing section. • …
- 11. State + Behavior
- 15. Traditional systems store current state.
- 16. We have no idea what has happened in our system.
- 18. State Audit log
- 20. Deposit 500 € 500 € Deposit 200 € 700 € Withdraw 300 € 400 € Deposit 1000 € 1400 € Withdraw 400 € 1000 € Withdraw 200 € 800 € … …
- 21. 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 € … …
- 22. Command - Event - State
- 23. Something that happened - past tense.
- 24. Store the sequence of events that led up to the current state, instead of the current state.
- 25. Command State Put up a new card “Reset Password” Card “Reset Password” “Todo” Move card to doing Card “Reset Password” “Doing” … …
- 26. 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” … … …
- 46. An event store
- 48. EventId StreamId Type Payload MetaData 1 card/1 CardPutUp { … } { … } 2 card/1 MovedCard ToSection { … } { … } 3 card/1 MovedCard ToSection { … } { … } … … … …
- 50. You can’t undo the past.
- 51. Append-only.
- 59. We can build a read model from events committed to the write model.
- 60. Events Dispatcher Projection Read model
- 61. Events Dispatcher Projection Read model Projection Read model
- 62. Events Dispatcher Projection Read model Projection Read model Projection Read model
- 63. We can build read models from events committed to the write model.
- 64. More than one way to look at your data.
- 79. 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?
- 81. Tell me which day most work gets done.
- 82. Monday Tuesday Wednesday … CardMoved CardMoved CardMoved CardMoved CardMoved CardMoved CardMoved CardMoved CardMoved CardMoved
- 84. Not just for read models and queries.
- 86. Events Dispatcher Projection Read model Projection Read model Projection Read model Integration
- 87. Pub-Sub
- 91. Events Dispatcher (Queue) Projection (Queue) Projection (Queue) Projection (Queue)
- 92. When?
- 93. When you can’t afford to lose data.
- 94. Business Intelligence Auditing Reproducing issues Challenging/changing business models
- 95. Decouple reads from writes
- 96. Conceptual purity Simplicity (no monolith) Polyglot persistance Performance High availability
- 97. Integration with other systems Testing …
- 98. No silver bullet
- 99. In conclusion
- 100. Event sourcing, for when the what and the when are important.
- 101. … but really, it’s a lot more than that.
- 102. Experiment!