158
schema evolution
Old files and new code must both still read. Adding a field is easy. Changing a meaning is not.
What is schema evolution?
Schema evolution is how records change across versions: add optional fields, do not reuse a tag to mean something else, do not change a type in place. Avro, Protobuf, and warehouse tables all have rules. “Just alter the column” breaks yesterday’s files.
Why does schema evolution matter when vibe coding?
Models rename a field in the event and the consumer. The backlog of old events still has the old name and the job dies. Name compatibility: backward, so new code reads old data.
How do you do schema evolution?
New code reads old and new. Writers move later. Never recycle a field id. Tests decode a fixture from last version.
How do you ask a model for schema evolution?
Evolve (schema) backward-compatibly. New consumers must read old events. Add fields; do not rename or reuse them in place. Include a fixture of the previous version in tests.
What goes wrong with schema evolution?
A “compatible” change that makes a formerly optional field required. Old writers are now invalid. That is a break.