Events schema versioning, or in other words, events evolution, is one of the first questions I get when explaining Event Sourcing. The topic may look scary, as how to evolve data that, by definition, is immutable.
I won’t lie; migrations are never easy., even in relational databases. You always have to think about the following:
What caused the change?
What are the possible solutions?
Is the change breaking?
What to do with old data?
When working in event schema evolution, you must ask yourself the same questions. Based on the answers, you need to choose your strategy.
During the webinar, I showed simple techniques that should take you far enough:
simple mapping scenarios, where serialiser features are good enough,
upcasting and downcasting, so how to transform our events on the fly to the latest schema or to the schema that’s compatible with previous versions,
explicit (de)serialisation to handle the payload transformation without additional magic,
more advanced scenarios.
All of that was put into a broader context together with considerations on how to apply that:
business logic and projections,
differences between environments like C#, Java, TypeScript,
using Marten and EventStoreDB, but also messaging tooling.
In the end, in Grand Finale, we also discussed the trick of not needing to do versioning at all!
You can also read my articles:
Source codes are available here:
Or just watch the webinar, as it’s all there and more!
For the advanced scenarios, read an excellent book by Greg Young, “Versioning in an Event Sourced System” (it’s available for free).
Become a paid subscriber and access the Miro board from the webinar!
#16 - Simple patterns for events schema versioning