Menu
Back to Discussions

Event schema evolution: how to change message formats without breaking consumers

Lars Voronova
Lars Voronova
·221 views
Event schema evolution is a recurring nightmare for us. We started with simple JSON messages, and it was fine until we began adding, removing, or renaming fields. This inevitably breaks consumers that expect the old schema, leading to deployment headaches and outages. We've tried manual versioning (e.g., `v1`, `v2` topics), but it quickly becomes unmanageable and leads to duplicate code. We're now looking into using Avro with a schema registry, which provides backward and forward compatibility by default and forces schema definition. This helps with structural changes, but it doesn't solve semantic changes (e.g., changing the meaning of a field without changing its type). What are your most effective strategies for evolving event schemas in a distributed system without breaking existing consumers? How do you handle deprecating fields, making breaking changes, and communicating these changes effectively across engineering teams?
0 comments

Comments

Sign in to join the conversation.

Loading comments...
Event schema evolution: how to change message formats without breaking consumers — SysDesAi Discussions | SysDesAi