ORIGINAL TECHNICAL PRACTICE
Evolve an event schema without breaking consumers
Several independent consumers read an event stream. How would you add a new field and later change the meaning of an existing one?
Written for independent practice. The model answer presents one approach; clarify constraints and explain alternatives.
A REASONED APPROACH
Model answer.
Treat event meaning and compatibility as explicit contracts. An optional additive field is often easier to roll out than changing the semantics of an existing field that old consumers still interpret.
Work through it
- Version schemas and document required fields, defaults, units and event-time meaning. Check compatibility with both producers and current consumers.
- Deploy tolerant consumer changes before producers rely on a new field. For a semantic breaking change, use a new version or event type and define a migration period.
- Replay representative historical events through updated consumers and test duplicate delivery, unknown fields and rollback. Preserve provenance so derived data can be rebuilt if interpretation changes.
Tradeoffs to discuss
- Dual publishing simplifies migration for some consumers while increasing traffic and reconciliation work. A strict schema can catch errors early but requires coordinated evolution.
Common pitfalls
- Reusing a field name for a different unit can silently corrupt downstream metrics. A schema registry does not by itself prove that the business meaning stayed compatible.