Compatibility types that keep producers and consumers in sync as schemas change

The piece defines schema evolution as safely changing schemas while existing producers and consumers keep working. Schema Registry checks each new version against prior versions using compatibility types: Backward (new consumers read old data; e.g. add optional fields, remove fields), Forward (old consumers read new data; e.g. remove optional fields, add fields), Full (both), and Transitive (checked against all previous versions, not only the last). The default mode is BACKWARD. Each version gets a unique ID and incremented version number; incompatible updates are rejected. Allowed changes depend on original field definitions—for example, deleting a field while staying compatible usually requires the field to have been optional or to have had a default. Coverage includes Avro, Protobuf, and JSON Schema, with JSON Schema also depending on lenient or strict policy settings.

For streaming and event teams, this is the control plane for shared message shapes. Without enforced compatibility, a field rename or a required-field addition can break consumers silently across Kafka subjects.

It treats schemas as versioned contracts with machine-checkable rules—shared meaning that producers, consumers, and registries agree on before data moves.