An event producer and its consumers rarely upgrade at the same moment. Backward compatibility lets consumers upgrade first: a consumer using the new schema can still read messages written with the previous schema. Old and new event versions can therefore coexist during a gradual rollout. section 6.2.5
In Kafka Schema Registry, compatibility mode is configured per subject. BACKWARD is the default mode. When a proposed schema violates that mode, the registry rejects its registration. This checks the data contract before the new version is used; it does not make Kafka brokers validate message contents. section 6.4.4 section 6.4.6
Changing a client profile
Suppose version V1 has a mandatory age field. Version V2 removes age and adds score with a default value. A V2 consumer reading a V1 message ignores age and supplies the default for the missing score. The consumer can be upgraded before producers begin writing V2 messages. section 6.4.4
Figure 6.14 An example of backward compatibility. The new consumer must understand the previous version of the schema.
The diagram shows the rollout direction: upgrade the consumer while messages written under the previous schema remain readable. section 6.4.4
The policy shapes both schema design and release planning:
- A new schema may delete a field that its consumer can ignore in older messages, or add an optional field with a default for messages that lack it. Renaming fields or changing their types may require a different migration strategy. section 6.4.4 section 6.4.6
- Publish schema changes where consumers can review them, notify consumer teams, and coordinate upgrades. Consumer-first deployment can be difficult when many independent teams own consumers. section 6.3.4 section 6.4.4
Backward compatibility is a constraint, not a solution for every change. If a required redesign breaks the contract, plan a migration—for example, drain old messages before switching versions, use separate versioned topics, or transform events between formats. Such transitions can require careful orchestration or downtime. section 6.5.2 section 6.2.5
