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

Event Sourcing architecture using Elixir (old version)

Event Sourcing architecture using Elixir (old version)

NEW SLIDE VERSION: https://speakerdeck.com/macabeus/event-sourcing-architecture-using-elixir

Talk at "Elug Meetups #13".

Video (in other meetup, using old slides version): https://youtu.be/tixWGkkZbXE
Projects used on this talk: https://github.com/macabeus/event-sourcing-example
My blog: http://macalogs.com.br/

Bruno Macabeus

April 07, 2018
Tweet

More Decks by Bruno Macabeus

Other Decks in Programming

Transcript

  1. “The core idea of event sourcing is that whenever we

    make a change to the state of a system, we record that state change as an event, and we can confidently rebuild the system state by reprocessing the events at any time in the future.” - Martin Fowler youtu.be/STKCRSUsyP0 bit.ly/martin-event-driven
  2. This architecture has many interesting benefits! Event log provides a

    strong audit capability We can recreate historic states by replaying the event log up to a point
  3. This architecture has many interesting benefits! We can explore alternative

    histories by injecting hypothetical events when replaying Event log provides a strong audit capability We can recreate historic states by replaying the event log up to a point
  4. This architecture has many interesting benefits! Event sourcing makes it

    plausible to have non-durable working copies, such as a Memory Image. We can explore alternative histories by injecting hypothetical events when replaying Event log provides a strong audit capability We can recreate historic states by replaying the event log up to a point
  5. This architecture has many interesting benefits! Event sourcing makes it

    plausible to have non-durable working copies, such as a Memory Image. We can explore alternative histories by injecting hypothetical events when replaying Event log provides a strong audit capability We can recreate historic states by replaying the event log up to a point
  6. This architecture has many interesting benefits! Event sourcing makes it

    plausible to have non-durable working copies, such as a Memory Image. We can explore alternative histories by injecting hypothetical events when replaying Event log provides a strong audit capability We can recreate historic states by replaying the event log up to a point
  7. User Server Current state: Events log: 0 User “creates" an

    event. An event represents something that happened, a fact
  8. User Server Current state: Events log: 0 In this example,

    the user “creates an event”. But, on the others implementations of this architecture, another part could create the events
  9. User Server Current state: Events log: 0 Event “arrives" on

    the server. On the others implementations, the server could “create" the event
  10. User Server Current state: Events log: +1 2 +1 Note

    that the events log aren’t the represent the final state
  11. User Server Current state: Events log: -1 1 +1 +1

    It’s a non-deterministic event
  12. User Server Current state: Events log: -1 5 +1 +1

    +4 Now the events log has too many events
  13. User Server Current state: Events log: -1 ?? +1 +1

    +4 +1 Snapshot: state 5 What if we lose the state?
  14. User Server Current state: Events log: -1 ?? +1 +1

    +4 +1 Snapshot: state 5 We could run again the events to restore the previous state! Using the events, we could convert the stream of events into a structural representation. This process is called “projection".
  15. Hey! It’s important the events be agnostic of a language,

    then you’ll can work using another languages on same project. Flux Standard Action is an example of solution about it. I didn't do it in my example. My example works only on Elixir
  16. - An in-memory database, Mnesia, using the wrapper Amnesia In

    this project, I used two databases: Mnesia
  17. - An in-memory database, Mnesia, using the wrapper Amnesia In

    this project, I used two databases: - A storage file database, DETS Mnesia DETS
  18. - An in-memory database, Mnesia, using the wrapper Amnesia In

    this project, I used two databases: - A storage file database, DETS Both, Mnesia and DETS, are in OTP! That is, built-in on Erlang/Elixir! Mnesia DETS OTP
  19. A projection is the transformation of a set of data

    from one form into another. In the case of event sourcing architecture, we convert a stream of events into any structural representation.
  20. A projection is the transformation of a set of data

    from one form into another. In the case of event sourcing architecture, we convert a stream of events into any structural representation. -1 +1 +1 +4
  21. CQRS: split the responsibility of "read" and “write" on the

    database. Reporting database: a database optimized for read. If a database is optimized for read, then could have redundancy and multiples databases to query.
  22. CQRS: split the responsibility of "read" and “write" on the

    database. Reporting database: a database optimized for read. If a database is optimized for read, then could have redundancy and multiples databases to query. And, applying it with event sourcing: we could have a database that centralize all events received by the system (“event storage”), and many small databases optimized to read. This both reads the same bus and be updates when a new event is forwarded on the bus.
  23. CQRS and Reporting Database aren’t exclusive for event sourcing. But,

    it’s useful when we are using event sourcing. !
  24. Commands are de requests issued by the user, and maybe

    fail. E.g: AddFunds When a command are performed, maybe it generates events - that is, facts about the application state changes E.g: FundsAdded
  25. VALIDATION Validations: checks if the command makes sense and objects

    are properly suited for further actions (is this event is to me?) Life cycle:
  26. VALIDATION CONSEQUENCE Validations: checks if the command makes sense and

    objects are properly suited for further actions (is this event is to me?) Consequences: initiating some action that will change the state of the world (do I need to forward a new event?) Life cycle:
  27. VALIDATION CONSEQUENCE DERIVATION Validations: checks if the command makes sense

    and objects are properly suited for further actions (is this event is to me?) Consequences: initiating some action that will change the state of the world (do I need to forward a new event?) Derivations: figuring out some information based on information we already have (I created a token and I’ll send it to user) Life cycle:
  28. User Event storage Create an account List accounts Send a

    validate e-mail Validate an account User can send a command on bus, and many process manager (PM) reads this bus…
  29. User Event storage Create an account List accounts Send a

    validate e-mail Validate an account User can send a command on bus, and many process manager (PM) reads this bus. Maybe a PM could send a new event on the bus.
  30. User Event storage Create an account Send a validate e-mail

    List accounts Validate an account User can send a command on bus, and many process manager (PM) reads this bus. Maybe a PM could send a new event on the bus. And, the PM needs read events in Event Storage, to re-build when it loses the data.
  31. User Event storage Create an account Send a validate e-mail

    List accounts Validate an account Events processing are asynchronous! User can send a command on bus, and many process manager (PM) reads this bus. Maybe a PM could send a new event on the bus. And, the PM needs read events in Event Storage, to re-build when it loses the data. And everything could be async!
  32. User Event storage Create an account Send a validate e-mail

    List accounts Validate an account Events processing are asynchronous! User can send a command on bus, and many process manager (PM) reads this bus. Maybe a PM could send a new event on the bus. And, the PM needs read events in Event Storage, to re-build when it loses the data. And everything could be async!
  33. User Event storage Create an account Send a validate e-mail

    List accounts Validate an account Events processing are asynchronous! User can send an event on bus, and many process manager (PM) reads this bus. Maybe a PM could send a new event on the bus. And, the PM needs read events in Event Storage, to re-build when it loses the data. And everything could be async!
  34. User Event storage Create an account Send a validate e-mail

    List accounts Validate an account Events processing are asynchronous! User can send an event on bus, and many process manager (PM) reads this bus. Maybe a PM could send a new event on the bus. And, the PM needs read events in Event Storage, to re-build when it loses the data. And everything could be async!
  35. User Event storage Create an account Send a validate e-mail

    List accounts Validate an account Events processing are asynchronous! User can send an event on bus, and many process manager (PM) reads this bus. Maybe a PM could send a new event on the bus. And, the PM needs read events in Event Storage, to re-build when it loses the data. And everything could be async!
  36. User Event storage Create an account Send a validate e-mail

    List accounts Validate an account Events processing are asynchronous! User can send an event on bus, and many process manager (PM) reads this bus. Maybe a PM could send a new event on the bus. And, the PM needs read events in Event Storage, to re-build when it loses the data. And everything could be async!
  37. User Event storage Create an account Send a validate e-mail

    List accounts Validate an account Events processing are asynchronous! User can send an event on bus, and many process manager (PM) reads this bus. Maybe a PM could send a new event on the bus. And, the PM needs read events in Event Storage, to re-build when it loses the data. And everything could be async!
  38. User Event storage Create an account Send a validate e-mail

    List accounts Validate an account Events processing are asynchronous! User can send an event on bus, and many process manager (PM) reads this bus. Maybe a PM could send a new event on the bus. And, the PM needs read events in Event Storage, to re-build when it loses the data. And everything could be async!
  39. User Event storage Create an account Send a validate e-mail

    List accounts Validate an account Events processing are asynchronous! User can send an event on bus, and many process manager (PM) reads this bus. Maybe a PM could send a new event on the bus. And, the PM needs read events in Event Storage, to re-build when it loses the data. And everything could be async!
  40. User Event storage Create an account Send a validate e-mail

    List accounts Validate an account Events processing are asynchronous! User can send an event on bus, and many process manager (PM) reads this bus. Maybe a PM could send a new event on the bus. And, the PM needs read events in Event Storage, to re-build when it loses the data. And everything could be async!
  41. User Event storage Create an account Send a validate e-mail

    List accounts Validate an account Events processing are asynchronous! User can send an event on bus, and many process manager (PM) reads this bus. Maybe a PM could send a new event on the bus. And, the PM needs read events in Event Storage, to re-build when it loses the data. And everything could be async!
  42. User Event storage Create an account Send a validate e-mail

    List accounts Validate an account Events processing are asynchronous! User can send an event on bus, and many process manager (PM) reads this bus. Maybe a PM could send a new event on the bus. And, the PM needs read events in Event Storage, to re-build when it loses the data. And everything could be async!
  43. User Event storage Create an account Send a validate e-mail

    List accounts Validate an account Events processing are asynchronous! User can send an event on bus, and many process manager (PM) reads this bus. Maybe a PM could send a new event on the bus. And, the PM needs read events in Event Storage, to re-build when it loses the data. And everything could be async!
  44. User Event storage Create an account Send a validate e-mail

    List accounts Validate an account Events processing are asynchronous! User can send an event on bus, and many process manager (PM) reads this bus. Maybe a PM could send a new event on the bus. And, the PM needs read events in Event Storage, to re-build when it loses the data. And everything could be async!
  45. User Event storage Create an account Send a validate e-mail

    List accounts Validate an account Events processing are asynchronous! User can send an event on bus, and many process manager (PM) reads this bus. Maybe a PM could send a new event on the bus. And, the PM needs read events in Event Storage, to re-build when it loses the data. And everything could be async!
  46. User Event storage Create an account Send a validate e-mail

    List accounts Validate an account Events processing are asynchronous! User can send an event on bus, and many process manager (PM) reads this bus. Maybe a PM could send a new event on the bus. And, the PM needs read events in Event Storage, to re-build when it loses the data. And everything could be async!
  47. User Event storage Create an account Send a validate e-mail

    List accounts Validate an account Events processing are asynchronous! User can send an event on bus, and many process manager (PM) reads this bus. Maybe a PM could send a new event on the bus. And, the PM needs read events in Event Storage, to re-build when it loses the data. And everything could be async!