Event Sourcing

Event Sourcing

What is Event Sourcing - How it works and how it can look like in TypeScript.

1e3f36cacc64d0a924cdbb3fdc59e8af?s=128

move:elevator

September 10, 2020
Tweet

Transcript

  1. Event Sourcing Why state is not a fact but a

    first class derivative of things that happened
  2. Who am I Frank Jogeleit @move:elevator GmbH Backend Engineer GitHub:

    https://github.com/fjogeleit Twitter: @FrankJogeleit
  3. Do you think your bank account balance is a column

    in a table?
  4. What is Event Sourcing? • Its used for • most

    financial systems like Banking-, Trading-, Gambling Software • healthcare like medical files • legal contracts For sure nothing new
  5. What is Event Sourcing • Proper Audit • Logging core

    idea
  6. „Event Sourcing says all state is transient and you only

    store facts“
  7. What is Event Sourcing? Traditional View Line Items (2) Purchase

    Order Shipping Informations
  8. What is Event Sourcing? Event Sourcing View Card created 3

    Items Added Item Removed Shipping Information Added Event Stream
  9. What is Event Sourcing? • Losing no Information • Explicit

    Time Information • No updates / deletes, only append • Who now which data will be valuable in the future? • State is a first class derivative What changes?
  10. What is Event Sourcing? • Past Data for future features

    • Reports • Events are use cases • Code reflect behavior • Recreate state at any point in time in the past New capabilities
  11. What is Event Sourcing? • Readmodels are a (persistent) representation

    of the current state of your application • Created as a left fold of your Event Stream in historical order • You can create as many Readmodels as you want for a single Event Stream • Readmodel persistence is independent from your Events, e.g. • InMemory for business decisions • Redis for short caches • SQL or NoSQL Databases for Views Readmodels
  12. CQRS Command Query Responsibility Separation

  13. What is CQRS? • Like the name already implies this

    pattern separate reading from writing operations • Your operation has return type void? -> Command • Your operation returns any value? -> Query • Queries must not change any state of your app • When you execute a query many times, the result has to be the same. (Assumed no other operations happened) Not much more as simple Pattern
  14. CQRS + Event Sourcing • Commands represent behavior and create

    one or many Events • The EventStore is the single source of truth • ReadModels could be used for business decisions(*) • Queries using Readmodels to return application state How they work together
  15. Side Effects • It many cases some kind of MessageBuses

    are used to implement the CQRS pattern • Beside a Command- and QueryBus you can use an EventBus to trigger some kind of Side Effect • An EventBus publish persisted (Domain) Events, so you can listen for it and execute related logic, for example • send a Registration E-Mail • trigger another related service to your event (Purchase- and Billing Service) EventBus / ProcessManager / Saga - you named it
  16. Trade Offs • Replaying many Events (really many) is time

    expensive, you can create snapshot but you also have to manage them • Creating Readmodels asynchronously can lead to concurrency problems • Events are immutable but in some cases like GDPR (DSVO) you have to anonymize Data • Event Sourcing with Files need additional work Event Sourcing is perfect, isn’t it? - Almost
  17. Bank Account API Event Sourcing by Example

  18. Event Sourcing by Example • Github: https://github.com/fjogeleit/event-sourcing-nodejs-example • NodeJS API

    Example with TypeScript, NestJS • Hosted Example http://event-sourcing-example.webdev-jogeleit.de/ • EventStore https://github.com/fjogeleit/event-store Bank Account API
  19. Questions?