Event-Sourcing with Elixir

Transcript

1. @phonnz Construyendo la máquina del tiempo [Event-Sourcing] @fonscodifica
2. Definition A system which source events in order to derive the state of an application. It is a design pattern that stores state changes as a sequence of events, allowing the state to be reconstructed at any time.
3. Definition A system which source events in order to derive the state of an application. • Commands • Events • Aggregates • Projections • EventStore
4. Use cases • Financial systems (Transactions) • E-commerce (Tracking) • IoT (Real-time events) • Healthcare (medical records)
5. • Distributed consistency • Scalability • Fault tolerant: data reconstruction GDPR y HIPAA. • Reactivity = resiliency. Problems it solves
6. Reasons
7. • Non-academic content Disclaimers • The story of “Empresa” may not be real but based on real events • Based on real-experience • We were young
10. EUR USD *Customer required to action payment
12. EUR USD *Customer required to action payment Price difference Not enough money Payment amount exceeded Split the payment Retry -> rate-limit -> handle time to retry *know the debt
13. Projections (or generated read models) Different Projectors can not Share Projections • Table views • Postgres triggers • Caching Must Not Read from Projections • Query data • execute in fixed (O(1)) time. Avoid multiple read models
15. Not enough money Payment amount exceeded Split the payment Retry -> rate-limit -> handle time to retry High risk
16. Ledgers theory! Ledger: transactions to charge, paid transactions. (bad debt) Actions: call to charge, update the ledger. (retry) *compute debt, partial payments, declined payments
17. • Table views • PubSub • Cachex [projector] • GenServer (only 1 [aggregate]) *multiple-instances, invalidated cache Ledgers theory! Ledger: transactions to charge, paid transactions. (bad debt) Actions: call to charge, update the ledger. (retry) *compute debt, partial payments, declined payments
18. Flows per process manager Never Manage More Than One Flow Per Process Manager
19. Flows per process manager Never Manage More Than One Flow Per Process Manager
20. Commands & Aggregates Ledgers theory! Ledger: transactions to charge, paid transactions. (bad debt) Actions: call to charge, update the ledger. (retry) *compute debt, partial payments, declined payments
21. Aggregates An entity which has state, validates commands, and emits events *associate your aggregate to an event_id
22. Aggregates
23. CQRS Command Query Responsibility Segregation - Perform action (command, handler) - Read data (Query) Commands: • :create order • :update_inventory • :withdraw_amount • :update_price Queries: • :view_order_history • :show_available_products *A command triggers an event
24. Events Something that happened All Events Are Immutable All Data Required for Event Sourcing Primitives Must Be on Events Events generated by producer and independent of consumers Human readable
25. * Require to know debt Declined batch payments
26. Event Store • CouchDB • EventStoreDB • PostgreSQL
27. EventType Events as schema validated by the publishers, not the consumer, consumer should receive anything • Establish naming (v1, v2) • Make consumer match the version • Write a handler between EventStore and Consumers
29. Time Machine • Full event history. • Distributed replication • Allows reconstructing the state looking for errors or inconsistencies. • Recover the state after failures.
30. Source: https://www.pwc.com/us/en/industries/financial-services/fintech/bitcoin-blockchain-cryptocurrency.html
31. Blockchain? Use case Event-Sourcing Blockchain Audit ✅ All events (Time machine!). ❌ Distributed entities Financials ✅ State reconstruction ❌ Distributed entities. Cryptocurrencies ❌ Centralized. ✅ Distributed and consensus. e-commerce ✅ Tracking. ❌ over-engineering. Voting systems ❌ Centralized. ✅ Distributed immutability. Supply-chain ❌ Work as side effect. ✅ Distributed entities.
32. Why the Time Machine? • Hyper-connected world • BEAM OTP ✅ • Distributed auditable consistency
34. Recurring trips Available back trips Match back trip Infered trips Suggested trips • Time to load • Time to unload • Vehicle type/capacity • Oil variants • Road costs • Routes • US enabled • Cost of trip • Best ROI • Negotiate
35. Why the Time Machine? • No big tasks, less complexity • BEAM OTP ✅ • Distributed auditable consistency • Hyper-connected world
42. Wrap: Must Event-Source Events should happened. Failure Events Should Not Change Aggregates Event is the starting point Events Are Immutable Event should have all data (or versioning) Projections come from events One flow per GenServer (account, order, etc) Managers Must Not Read from Projections
43. Resources • Domain Driven Design - Vernon Vaughn • Elixir's Ecto: Functional-Relational Data Access Done Right • Brad Urani • YOW! 2019 @phonnz @fonscodifica https://github.com/phonnz/coin_exchange • Real-World Event Sourcing - Kevin Hoffman