Comparison
Backward compatibilityvsSchema evolution
Backward compatibility
you add the field as optional so the clients that have never heard of it keep working unchanged.
The property that existing callers keep working against the new version. It is the constraint that governs every API change once you do not control all clients. The practical rules are small: add optional, never remove or rename, never narrow a type, never add a required field, never change the meaning of an existing value.
Full entry →Schema evolution
you change the message format and have to make sure the consumers still on the old schema can read the new messages.
Managing changes to a serialisation contract so producers and consumers can be deployed independently. Formats like Avro and Protobuf encode the rules — optional fields, reserved tags, never reuse a field number — and a schema registry enforces them. The rules exist because in any rolling deploy the producer and consumer are briefly on different versions.
Full entry →