Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Event-Sourcing with Elixir

phonnz
February 27, 2025

Event-Sourcing with Elixir

phonnz

February 27, 2025
Tweet

More Decks by phonnz

Other Decks in Programming

Transcript

  1. 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.
  2. Definition A system which source events in order to derive

    the state of an application. • Commands • Events • Aggregates • Projections • EventStore
  3. Use cases • Financial systems (Transactions) • E-commerce (Tracking) •

    IoT (Real-time events) • Healthcare (medical records)
  4. • Distributed consistency • Scalability • Fault tolerant: data reconstruction

    GDPR y HIPAA. • Reactivity = resiliency. Problems it solves
  5. • Non-academic content Disclaimers • The story of “Empresa” may

    not be real but based on real events • Based on real-experience • We were young
  6. 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
  7. 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
  8. Not enough money Payment amount exceeded Split the payment Retry

    -> rate-limit -> handle time to retry High risk
  9. Ledgers theory! Ledger: transactions to charge, paid transactions. (bad debt)

    Actions: call to charge, update the ledger. (retry) *compute debt, partial payments, declined payments
  10. • 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
  11. 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
  12. Aggregates An entity which has state, validates commands, and emits

    events *associate your aggregate to an event_id
  13. 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
  14. 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
  15. 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
  16. Time Machine • Full event history. • Distributed replication •

    Allows reconstructing the state looking for errors or inconsistencies. • Recover the state after failures.
  17. 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.
  18. Why the Time Machine? • Hyper-connected world • BEAM OTP

    ✅ • Distributed auditable consistency
  19. 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
  20. Why the Time Machine? • No big tasks, less complexity

    • BEAM OTP ✅ • Distributed auditable consistency • Hyper-connected world
  21. 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
  22. 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