Event-Sourcing with Elixir

Slide 1

Slide 1 text

@phonnz Construyendo la máquina del tiempo [Event-Sourcing] @fonscodiﬁca

Slide 2

Slide 2 text

Deﬁnition 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.

Slide 3

Slide 3 text

Deﬁnition A system which source events in order to derive the state of an application. ● Commands ● Events ● Aggregates ● Projections ● EventStore

Slide 4

Slide 4 text

Use cases ● Financial systems (Transactions) ● E-commerce (Tracking) ● IoT (Real-time events) ● Healthcare (medical records)

Slide 5

Slide 5 text

● Distributed consistency ● Scalability ● Fault tolerant: data reconstruction GDPR y HIPAA. ● Reactivity = resiliency. Problems it solves

Slide 6

Slide 6 text

Reasons

Slide 7

Slide 7 text

● Non-academic content Disclaimers ● The story of “Empresa” may not be real but based on real events ● Based on real-experience ● We were young

Slide 8

Slide 8 text

No content

Slide 9

Slide 9 text

No content

Slide 10

Slide 10 text

EUR USD *Customer required to action payment

Slide 11

Slide 11 text

No content

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

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 ﬁxed (O(1)) time. Avoid multiple read models

Slide 14

Slide 14 text

No content

Slide 15

Slide 15 text

Not enough money Payment amount exceeded Split the payment Retry -> rate-limit -> handle time to retry High risk

Slide 16

Slide 16 text

Ledgers theory! Ledger: transactions to charge, paid transactions. (bad debt) Actions: call to charge, update the ledger. (retry) *compute debt, partial payments, declined payments

Slide 17

Slide 17 text

● 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

Slide 18

Slide 18 text

Flows per process manager Never Manage More Than One Flow Per Process Manager

Slide 19

Slide 19 text

Flows per process manager Never Manage More Than One Flow Per Process Manager

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

Aggregates An entity which has state, validates commands, and emits events *associate your aggregate to an event_id

Slide 22

Slide 22 text

Aggregates

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

* Require to know debt Declined batch payments

Slide 26

Slide 26 text

Event Store ● CouchDB ● EventStoreDB ● PostgreSQL

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

No content

Slide 29

Slide 29 text

Time Machine ● Full event history. ● Distributed replication ● Allows reconstructing the state looking for errors or inconsistencies. ● Recover the state after failures.

Slide 30

Slide 30 text

Source: https://www.pwc.com/us/en/industries/ﬁnancial-services/ﬁntech/bitcoin-blockchain-cryptocurrency.html

Slide 31

Slide 31 text

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.

Slide 32

Slide 32 text

Why the Time Machine? ● Hyper-connected world ● BEAM OTP ✅ ● Distributed auditable consistency

Slide 33

Slide 33 text

No content

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

Why the Time Machine? ● No big tasks, less complexity ● BEAM OTP ✅ ● Distributed auditable consistency ● Hyper-connected world

Slide 36

Slide 36 text

No content

Slide 37

Slide 37 text

No content

Slide 38

Slide 38 text

No content

Slide 39

Slide 39 text

No content

Slide 40

Slide 40 text

No content

Slide 41

Slide 41 text

No content

Slide 42

Slide 42 text

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 ﬂow per GenServer (account, order, etc) Managers Must Not Read from Projections

Slide 43

Slide 43 text

Resources ● Domain Driven Design - Vernon Vaughn ● Elixir's Ecto: Functional-Relational Data Access Done Right • Brad Urani • YOW! 2019 @phonnz @fonscodiﬁca https://github.com/phonnz/coin_exchange ● Real-World Event Sourcing - Kevin Hoffman