Learn about event versioning approaches and their pros and cons and how to safely evolve event schemas without breaking existing consumers.

TheBurningMonk's blog is a platform for sharing insights and expertise in cloud computing, serverless architecture, and distributed systems design. Through articles, tutorials, and case studies, TheBurningMonk offers insights into building scalable, resilient, and cost-effective cloud-native applications using serverless technologies. Readers can learn about architectural patterns, deployment strategies, and best practices for designing serverless applications that leverage the scalability and flexibility of cloud platforms. Additionally, TheBurningMonk provides updates on the latest developments in serverless frameworks, cloud services, and event-driven architectures to help developers stay ahead of the curve and harness the full potential of serverless computing.

theburningmonk.com

The post discusses various strategies for versioning event schemas in event-driven architectures, including adding versions in event names, event payloads, separate streams, and using schema registries. It evaluates the pros and cons of each method and suggests alternative approaches to avoid breaking changes. The author emphasizes the importance of supporting backward compatibility and recommends always adding new fields instead of breaking existing schemas.

Event versioning strategies for event-driven architectures

2. Add version in the event payload/metadata

4. Use a schema registry and schema ID in the event

6. Out-of-band translation from new event versions

interesting, but no.
If event is breaking changed - you probably wanna to update all the consumers.
So, even if you have A LOT of it, spend 1-2 weeks, and you good.
You dont break change every week, so once a year(for example) you can go and update all the consumers.
If event is just improved without breaking change - the solution is much more simpler. Update only needed consumers.
So, if event is breaking changed - in the end all the consumers would use new version of it. So go to services, write coordination logic(all the consumers are ready to new event), then release new event, then go to consumers second time and remove temporary coordination logic.
Clean, obvious and robust solution.
Each author way - about increasing complexity. As a developers we must reduce it instead