Storing data as a sequence of events (RubyConfAt)

Transcript

1. Helping Rails apps since 2007 a boutique consultancy specializing in Ruby expertise
2. Relational Database
3. CRUD
4. Change = State Overwrite
5. Admit.
6. Information is lost
7. WHAT IT IS NOW
8. HOW WE GOT THERE
9. HOW WE GOT THERE
10. Alternative for saving data as snapshot
11. Storing state as sequence of facts
12. Facts == Events
13. Event Sourcing
14. ONE THING TO REMEMBER FROM THIS PRESENTATION
15. Event Sourcing is just another persistence technique.
16. Event
17. Events are kept in Event Store
18. Append only log
19. Immutable
20. Event <-> Stream
34. HOW WE GOT THERE?
38. One to Many
39. Load the state Make decision Publish an event (new state)
40. Consolidate events into streams to answer interesting business questions
52. Event Store… DB?
53. Rails Event Store Backed up and maintained by
54. Started in 2015
55. Based on Database that you already use
56. Two Tables Events and Events in streams
57. Comes with migrations
58. Comes with event browser
59. Case - Warehouse
60. Shipment
61. Packing
62. Mistakes happen
63. Information?
64. shipment.status == :packed
65. So it’ll be billed for packing…
66. So it’ll be billed for packing… Once
67. Demo
68. Benefits - State change history recorded as sequence of events - ZERO DATA LOSS - Auditability - Reconstructing state - Makes debugging easier
69. Check it out at railseventstore.org
70. THANK YOU! Łukasz Reszke