What if we stored events instead of state?

4,398 views
4,345 views

Published on

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.

Published in: Technology, Business
0 Comments
5 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
4,398
On SlideShare
0
From Embeds
0
Number of Embeds
14
Actions
Shares
0
Downloads
20
Comments
0
Likes
5
Embeds 0
No embeds

No notes for slide

What if we stored events instead of state?

  1. 1. WHAT IF WE STORED EVENTS INSTEAD OF STATE?
  2. 2. @JefClaes - jefclaes.be
  3. 3. SCENARIO’S • The user can put up a card. • The user can move the card to the doing section. • …
  4. 4. COMMANDS • Put up a card. • Move card to doing section. • …
  5. 5. State + Behavior
  6. 6. Traditional systems store current state.
  7. 7. We have no idea what has happened in our system.
  8. 8. Audit logs anyone?
  9. 9. State Audit log
  10. 10. Deposit 500 € 500 € Deposit 200 € 700 € Withdraw 300 € 400 € Deposit 1000 € 1400 € Withdraw 400 € 1000 € Withdraw 200 € 800 € … …
  11. 11. 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 € … …
  12. 12. Command - Event - State
  13. 13. Something that happened - past tense.
  14. 14. Store the sequence of events that led up to the current state, instead of the current state.
  15. 15. Command State Put up a new card
 “Reset Password” Card
 “Reset Password”
 “Todo” Move card to doing Card
 “Reset Password”
 “Doing” … …
  16. 16. 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” … … …
  17. 17. thinkbeforecoding.com
  18. 18. An event store
  19. 19. EventId StreamId Type Payload MetaData 1 card/1 CardPutUp { … } { … } 2 card/1 MovedCard ToSection { … } { … } 3 card/1 MovedCard
 ToSection { … } { … } … … … …
  20. 20. You can’t undo the past.
  21. 21. Append-only.
  22. 22. Forever cacheable.
  23. 23. What about queries?
  24. 24. Model Writes Reads
  25. 25. Write model Writes
  26. 26. Write model Writes Read model Reads
  27. 27. Write model Writes Read model Reads Events
  28. 28. We can build a read model 
 from events committed to the write model.
  29. 29. Events Dispatcher Projection Read model
  30. 30. Events Dispatcher Projection Read model Projection Read model
  31. 31. Events Dispatcher Projection Read model Projection Read model Projection Read model
  32. 32. We can build read models 
 from events committed to the write model.
  33. 33. More than one way to look at your data.
  34. 34. Behavior
 Search
 Reporting
 Views
 …

  35. 35. Complex
 Slow
 Fragile

  36. 36. 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?
  37. 37. Temporal queries.
  38. 38. Tell me which day most work gets done.
  39. 39. Monday Tuesday Wednesday … CardMoved CardMoved CardMoved CardMoved CardMoved CardMoved CardMoved CardMoved CardMoved CardMoved
  40. 40. Not just for read models and queries.
  41. 41. Events Dispatcher Projection Read model Projection Read model Projection Read model Integration
  42. 42. Pub-Sub
  43. 43. Events Dispatcher Projection Projection Projection Transaction
  44. 44. Events Dispatcher Projection Projection Projection
  45. 45. Events Projection Projection Projection
  46. 46. Events Dispatcher (Queue) Projection (Queue) Projection (Queue) Projection (Queue)
  47. 47. When?
  48. 48. When you can’t afford to lose data.
  49. 49. Business Intelligence
 Auditing
 Reproducing issues
 Challenging/changing business models
  50. 50. Decouple reads from writes
  51. 51. Conceptual purity
 Simplicity (no monolith)
 Polyglot persistance
 Performance
 High availability

  52. 52. Integration with other systems
 Testing
 …
  53. 53. No silver bullet
  54. 54. In conclusion
  55. 55. Event sourcing, for when the 
 what and the when are important.
  56. 56. … but really, it’s a lot more than that.
  57. 57. Experiment!
  58. 58. http://neventstore.org/ http://geteventstore.com/
  59. 59. https://groups.google.com/forum/#!forum/dddcqrs
  60. 60. @gregyoung @abdullin @randompunter @jonathan_oliver @jen20 @yreynhout @mathiasverraes @thinkb4coding @eulerfx @ziobrando @tojans
  61. 61. Thank you! @JefClaes
 http://jefclaes.be

×