Backward compatibility lets updated consumers read records written with either a new schema or the immediately previous schema. The migration sequence updates consumers first, then producers, so records may arrive in both formats during rollout. section 3.4.1
Apply backward compatibility through these schema changes:
- Delete fields that consumers no longer require. section 3.4.1
- Add optional fields by supplying a default value; deserialization uses that default when older serialized bytes omit the field. section 3.4.1
- Validate the change with Schema Registry, which can enforce compatibility globally or per subject. section 3.4
- Choose BACKWARD_TRANSITIVE when the new schema must remain compatible with every earlier version rather than only the immediate predecessor. section 3.4
Rolling out an optional field
Suppose a producer’s record gains an optional field with a default value. First deploy consumers that understand the new schema and can supply the default when reading old records. Then deploy producers that write the new schema. During the transition, consumers handle records from both producer versions. section 3.4.1
Figure 3.9 Backward compatibility updates consumers first to use the new schema. Then, they can handle records from producers using either the new schema or the previous one.
Use the migration diagram to track the consumer-first rollout and the two schema versions that consumers must accept. section 3.4.1
Schema Registry provides compatibility checks and serializers or deserializers for Avro, Protobuf, and JSON Schema. Kafka Streams applications follow the same schema-evolution rules because they contain both consumer and producer clients. section 3.9 section 6.4.5
