Schema evolution
The process of changing a message schema over time while maintaining compatibility with existing producers and consumers. Governed by the Schema Registry's compatibility rules: backward compatibility allows old consumers to read new messages; forward compatibility allows new consumers to read old messages; full compatibility satisfies both.
Schema evolution is unavoidable in any long-lived event-driven system. Fields are added, renamed, deprecated, or retyped as the system's understanding of its data matures. Without governance, these changes break the pipeline - producers publish messages that consumers cannot parse, or consumers fail on missing required fields. The Schema Registry enforces compatibility rules at registration time: before a new schema version is accepted, it is validated against all existing versions under the configured compatibility mode. Backward compatibility (the most common default) ensures that a consumer using an older schema version can still read messages written with the newer schema. This typically means new fields must have defaults and fields cannot be removed or retyped incompatibly. The Schema Registry's version history and compatibility checks turn schema evolution from a source of production incidents into a governed, auditable process.