Forward compatibility lets producers adopt a new event schema first while older consumers continue processing the resulting messages. Older consumers ignore unfamiliar fields and use defaults for missing optional fields, allowing versions to coexist during gradual migration. section 6.2.5 section 6.4.4
Apply the policy through schema rules rather than consumer-specific conversion code:
- Add fields that older consumers can ignore. section 6.4.4
- Delete optional fields when older consumers can supply their default values. section 6.4.4
- Reject changes such as renaming fields or altering their data types when they could break deserialization. section 6.2.5
- Validate schema versions in the Schema Registry to prevent incompatible messages from reaching consumers. section 6.2.5
Adding address while retiring score
A producer moves from V1 to V2 by removing the optional score attribute and adding address. An older V1 consumer ignores address and assigns the default value to score, so the producer can be upgraded first. section 6.4.4
Figure 6.15 An example of forward compatibility. The old consumer must understand the new version of the schema.
Use the forward-compatibility diagram to trace the producer-first rollout and the old consumer's interpretation of the new schema. section 6.4.4
