Lifecycle of a Schema Field — From Added to Removed Safely Diagram

New fields are safe only when old readers ignore what they do not know — so deploy code that reads the field before code that writes it
An optional field with a default is the cheapest kind of change; renaming or changing a type is really remove plus add
During a rolling upgrade both versions run side by side, so every message must be readable by both
Downgrading code is the test that keeps you honest: does last month's build still work on today's data?

A field may start being written only after every writer that could break on it is gone
A field may be removed only after every reader that still needs it is gone
Data outlives code: old messages, backups and archived files keep their schema forever
Versioned formats let a reader ask what version it is holding instead of guessing from bytes

Making a required field optional, changing a default, or reusing a field number are all breaking in disguise
Avro resolves with writer's and reader's schema; Protobuf relies on field numbers never being reused
Databases have the same problem at a larger timescale: rows written years ago must still be readable
A schema registry turns these rules into an enforced check instead of a team convention