DDDEurope 2018 - Event Sourcing After Launch

Event sourcing can be a solution for certain problems in your application, but it also comes with its own set of challenges. One of those is the evolution of your event schema. How should you handle changes to events?

We found many approaches while doing our research (we’ve published earlier results in our paper “The Dark Side of Event Sourcing”) and we gained a lot of experienced from building a full-size ERP application using CQRS and event sourcing. In this talk we will show what kind of approaches we’ve found and what we use to deal with our specific challenges. We will also share early research results from our interviews with over 20 different companies using event sourcing.

Every request for advice can be answered with ‘it depends’, and this talk will not solve that. But we will tell you what your options are, what we think works, and what many others have done.

Transcript

1. Event Sourcing after launch
   how to evolve your event store along with your application
   Michiel Overeem, AFAS, @michielovereem
   

   View Slide

2. “Versioning in
   event sourced systems
   is a big problem”
   

   View Slide

3. “We dreaded the upgrading.
   We had some fear in advance.”
   

   View Slide

4. “There is not much literature about it”
   

   View Slide

5. How to evolve your event store along with your application?
   

   View Slide

6. 20 years of ERP
   10.000 customers
   90% cloud
   Web
   Scalable
   CQRS
   Event sourcing
   

   View Slide

7. 20 years of ERP
   10.000 customers
   90% cloud
   Person
   Entity
   Customer
   Role
   Order
   Agreement
   party
   Spending limit
   Address
   Organisation
   Entity
   Delivery
   BusinessAc tivity
   party
   Invoice
   BusinessAc tivity
   party
   Address
   Address
   Spending limit
   Spending limit
   Own Organisation
   Workarea
   workarea
   Spending limit
   Put all our knowledge and
   experience in a model
   

   View Slide

8. Customized
   Web
   Scalable
   CQRS
   Event sourcing
   Person
   Entity
   Customer
   Role
   Order
   Agreement
   party
   Spending limit
   Address
   Organisation
   Entity
   Delivery
   BusinessAc tivity
   party
   Invoice
   BusinessAc tivity
   party
   Address
   Address
   Spending limit
   Spending limit
   Own Organisation
   Workarea
   workarea
   Spending limit
   

   View Slide

9. How to evolve your event store along with your application?
   

   View Slide

10. View Slide

11. 24 interviews
    on event sourcing
    and upgrades
    

    View Slide

12. Branches, domains
    

    View Slide

13. Prevention Techniques Pruning Privacy
    Read
    models
    

    View Slide

14. View Slide

15. Which streams are in the store?
    Which event types are in which stream?
    Which attributes does an event have?
    

    View Slide

16. Applications that do not evolve in response to changing
    requirements or changing technology become less useful
    -Lehman, 1974
    

    View Slide

17. View Slide

18. Prevention is better than a cure
    

    View Slide

19. View Slide

20. View Slide

21. State
    State’
    Event
    

    View Slide

22. Events = Transactions
    Or not?
    

    View Slide

23. Domain-driven design
    Events = real world events
    

    View Slide

24. “You align the events with real world events.
    You are dealing with changes that
    have a native equivalence.
    Doing DDD leads to less fragile design.”
    

    View Slide

25. See what sticks
    Life before and after release
    

    View Slide

26. How implicit is your schema?
    

    View Slide

27. What if prevention is no longer possible?
    

    View Slide

28. Versioned Events
    only introduce new events and streams
    2/24
    

    View Slide

29. “I try to keep my
    domain abstraction pure."
    

    View Slide

30. Weak Schema
    aka tolerant reader
    11/24
    

    View Slide

31. Easy, but incomplete
    

    View Slide

32. Upcasters
    Transform at runtime
    12/24
    

    View Slide

33. “The approach I took, and which is my impression that
    everyone takes …”
    

    View Slide

34. “Then we made our upcasters permanent…”
    

    View Slide

35. Immutability, not a binaire option
    

    View Slide

36. “So one of the things you should never ever do is change existing
    events. An event written persisted to datastore is not like a hand
    wavy thing. It is a fact.”
    

    View Slide

37. “Historians rewrite the past too…”
    

    View Slide

38. “These rewrites aren't destructive first of all.”
    

    View Slide

39. Data Information
    

    View Slide

40. “When your events form a contract with the outside, you
    have to keep those.”
    

    View Slide

41. In-place transformation
    Just as in the old days
    5/24
    

    View Slide

42. “Now that would pretty much break the whole premise of
    having a proper audit trail.”
    

    View Slide

43. Copy-transform
    When you just need to start over
    14/24
    

    View Slide

44. Variations
    1. Create a new store from the old one.
    2. Create a new stream inside of the store, based on old streams.
    3. Create new events in an existing stream.
    

    View Slide

45. “if you have like 10 billion events you just can't do it”
    

    View Slide

46. Versioned
    Events
    Weak
    Schema
    Upcasters In-Place
    Copy-
    Transform
    14/24
    5/24
    12/24
    11/24
    2/24
    

    View Slide

47. Does my event store look big?
    

    View Slide

48. Year ending Classified ads
    

    View Slide

49. Privacy…
    Privacy
    

    View Slide

50. “I really don’t know”
    

    View Slide

51. Custom event
    store structure Encryption
    Destructive
    technique
    

    View Slide

52. What about all those read models?
    

    View Slide

53. Rebuilt Sync
    

    View Slide

54. Prevention Techniques Pruning Privacy
    Read
    models
    24 interviews on event sourcing and
    upgrades
    Event sourced systems after launch are not scary
    

    View Slide

55. It depends. Your context. Your solution.
    

    View Slide

56. So, what is our solution?
    1. Copy-transform of the whole store
    1. 100.000 events in 4.5 minute (around 360 per sec)
    2. Rebuilt query side
    1. All projectors run in parallel
    3. We deploy in blue-green
    

    View Slide

57. What do we (think we) want?
    1. Renames are solved on the model level
    2. Weak schema: handle new attributes with ease
    3. Upcasters: solve complex cases without long delays
    4. Copy-transform:
    1. Remove upcasters
    2. Only those streams that need it
    5. Only rebuilt projections when necessary
    

    View Slide

58. Copyright Nasa Goddard
    Michiel Overeem
    @michielovereem
    Event Sourced Systems after launch:
    1. Prevention
    2. Techniques for upgrading
    3. Prune your store
    4. Think about privacy
    5. Rebuilt your read models
    

    View Slide