Event schema evolution: how to change message formats without breaking consumers
Liam Nielsen
·487 views
event schema evolution has been a persistent pain point for us. we've had incidents where adding a new field, or worse, renaming one, has broken downstream consumers because they weren't updated in sync. we looked into avro with a schema registry, and it definitely helps with backward and forward compatibility for structural changes.
but what about semantic changes? if we change the meaning of an existing field, even if the schema is technically compatible, it can still break logic. we've experimented with versioning topics or events (e.g., `user_v1`, `user_v2`), but that feels like a lot of overhead. how do people manage schema evolution robustly in microservice architectures with many consumers without constantly coordinating deployments or running multiple versions of consumers indefinitely? looking for practical strategies beyond just 'use avro'.
4 comments