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

DDD BELGIUM 2017 - The Dark Side of Event Sourcing

DDD BELGIUM 2017 - The Dark Side of Event Sourcing

Evolving software systems often includes data schema changes, and those cause the need for data conversion. This is no different in event sourced systems.

Converting data between schemas while continuing the operation of the system is a challenge.

In this talk, we will look at the possible conversion operations, the techniques to execute them, and strategies for deployment with zero-downtime.

We will look at the possibilities and the trade-offs for designing and implementing upgrades for event sourced systems.

Michiel Overeem

March 22, 2017
Tweet

More Decks by Michiel Overeem

Other Decks in Technology

Transcript

  1. The Dark Side of Event Sourcing Managing Data Conversion Michiel

    Overeem, Marten Spoor, Slinger Jansen
  2. AFAS Software 400 employees 100 million euro revenue

  3. None
  4. x 10.000

  5. Adaptable Model-based and User-specific Software Ecosystems

  6. Copyright Nasa Goddard

  7. How can an event sourced system be upgraded efficiently when

    the (implicit) event schema changes?
  8. None
  9. type Attribute = string * System.Object type Event = string

    * Attribute[] type EventStream = string * (Event[] * System.DateTime)[] type EventStore = EventStream[] The structure of an Event Store
  10. But there is also a schema Which streams are known

    in the system? Which events are allowed in which streams? Which attributes are allowed in which events?
  11. Example schema: webshop Webshop EventStore Customer Stream ShoppingCart Stream CustomerSignedUp

    PriviligeUpgraded … AddedToChart ChangedQuantity …
  12. Store level operations Add / remove streams Merge streams /

    split / … streams Stream level operations Add / remove events Merge events / split / … events Event level operations Add / update / remove attributes Merge attributes / split / … attributes How can we change it?
  13. Multiple versions: always extend Webshop EventStore Customer Stream ShoppingCart Stream

    CustomerSignedUp PriviligeUpgraded … AddedToChart ChangedQuantity …
  14. Multiple versions: always extend Webshop EventStore Customer Stream ShoppingCart Stream

    CustomerSignedUp PriviligeUpgraded … AddedToChart ChangedQuantity … Article Stream AddedToAssortment SoldOut …
  15. Multiple versions: always extend Webshop EventStore Customer Stream ShoppingCart Stream

    CustomerSignedUp PriviligeUpgraded … AddedToChart ChangedQuantity … Article Stream AddedToAssortment SoldOut … ChangedQuantity_V2
  16. Is this maintainable? Becomes the codebase to complex?

  17. Weakening the schema Which attributes can occure in which events?

    Which events can occure in which streams? Which streams can originate in the system?
  18. Weak schema’s Webshop EventStore Customer Stream ShoppingCart Stream CustomerSignedUp PriviligeUpgraded

    … AddedToChart ChangedQuantity …
  19. Weak schema’s Webshop EventStore Customer Stream ShoppingCart Stream CustomerSignedUp PriviligeUpgraded

    … AddedToChart ChangedQuantity … ChangedQuantity
  20. Explosion of code paths? And still not all operations are

    possible.
  21. Webshop EventStore Customer Stream ShoppingCart Stream CustomerSignedUp PriviligeUpgraded … Upcasters:

    Evolve the events AddedToChart ChangedQuantity …
  22. Webshop EventStore Customer Stream ShoppingCart Stream CustomerSignedUp PriviligeUpgraded … Upcasters:

    Evolve the events AddedToChart ChangedQuantity … ChangedQuantity_V2 CustomerSignedUp_V2
  23. What is the run-time overhead? Are all operations possible?

  24. Beware of the projectors! Order of upgrading components still matters!

  25. Beware of the projectors! Order of upgrading components still matters!

  26. Beware of the projectors! Order of upgrading components still matters!

  27. Store level operations Add / remove streams Merge streams /

    split / … streams Stream level operations Add / remove events Merge events / split / … events Event level operations Add / update / remove attributes Merge attributes / split / … attributes Can we perform all operations?
  28. Store level operations Add / remove streams Merge streams /

    split / … streams Stream level operations Add / remove events Merge events / split / … events Event level operations Add / update / remove attributes Merge attributes / split / … attributes Can we perform all operations?
  29. Copyright Stephen Cairns Technical versus functional immutability

  30. Lazy transformation

  31. But when is this finished? Mixed appends and updates.

  32. In place transformation Just find the events and fix them.

  33. Not for the faint of heart!

  34. Copy and transformation

  35. Change all the things! Auto backup. Could be very slow.

  36. Multiple versions Weak schema Upcasters Lazy transformation In place transformation

    Copy and transformation Functional suitability +/- - +/- +/- + + Comparing the approaches
  37. Multiple versions Weak schema Upcasters Lazy transformation In place transformation

    Copy and transformation Maintainability Comparing the approaches - +/- +/- +/- + +
  38. Multiple versions Weak schema Upcasters Lazy transformation In place transformation

    Copy and transformation Performance efficiency + + + +/- +/- - Comparing the approaches
  39. Multiple versions Weak schema Upcasters Lazy transformation In place transformation

    Copy and transformation Reliability + + + - - + Comparing the approaches
  40. Copyright SpaceX

  41. Schema versioning Multiple versions Weak schema Upcasters Lazy transformation In

    place transformation Copy and transformation Schema evolution
  42. Runtime techniques Multiple versions Weak schema Upcasters Lazy transformation In

    place transformation Copy and transformation Non-runtime techniques
  43. Big flip

  44. Big flip

  45. Big flip

  46. Big flip

  47. Big flip

  48. Blue-Green

  49. Blue-Green

  50. Blue-Green

  51. Blue-Green

  52. Blue-Green

  53. Rolling upgrade

  54. Rolling upgrade

  55. Rolling upgrade

  56. Rolling upgrade

  57. Rolling upgrade

  58. But for schema evolution we need another strategy for database

    deployment.
  59. Blue-Green

  60. Blue-Green

  61. Blue-Green

  62. Expand- Contract

  63. Expand- Contract

  64. Expand- Contract

  65. Expand- Contract

  66. Combining everything into a framework Data upgrade Deployed with Executed

    by Executed by Data upgrade Application upgrade Lazy transformation Upcasting In place transfor- mation Multiple versions Copy and transfor- mation Basic & Complex Event Basic & Complex Stream Basic Store Complex Store Big Flip Rolling Upgrade Blue-Green Expand- Contract Blue- Green Deployed with Combined with Weak schema
  67. But what about the query side?

  68. Early interview results

  69. Do you read your events ever again? No? Then just

    change the snapshot.
  70. Move out all events belonging to old aggregates.

  71. Nobody uses lazy transformation.

  72. Domain driven design helps in preventing changes.

  73. There is a lack of experience sharing.

  74. What’s next? 1. Do interviews. Interested? Contact me! https://goo.gl/forms/7tuBKW39EPkWnZLG3 1.

    Write a follow up paper with more information. 2. Publish the experiences in some form.
  75. Your context determines the best upgrade strategy. m.overeem@afas.nl @michielovereem