Schema evolution is how table or event schemas change over time: new columns, dropped fields, type changes, renamed keys.
v1 event: {id, amount}
v2 event: {id, amount, currency} # additive, usually safe
v3 event: {id, amount_cents} # rename/type change, dangerousSafer practices
- Prefer additive changes (new optional columns)
- Use schema registries for Kafka (compat rules: backward/forward)
- In lakes, table formats can evolve metadata carefully
- Version contracts; communicate breaking changes
- Make consumers tolerant of unknown fields when possible
Breaking changes need a migration plan
Dual-write, dual-read, backfill, then cut over.
Interview tip: Classify additive vs breaking, then mention compatibility modes and coordinated migrations.