Apache Kafka
Schema Registry & Evolution
Let producers and consumers evolve message formats independently without breaking each other.
In a long-lived event stream, producers and consumers are deployed at different times and evolve separately. If a producer changes a message format, old consumers can break. A Schema Registry solves this by storing versioned schemas (Avro, Protobuf, or JSON Schema) centrally and enforcing compatibility rules.
A shared API contract kept in version control with a linter: anyone can propose a new version, but the linter blocks a change that would break existing callers before it is merged.
Key Concepts
1
Messages carry a small schema id instead of the full schema, so payloads stay compact; consumers fetch and cache the schema by id to deserialize. The registry enforces a compatibility mode — backward (new consumers read old data), forward (old consumers read new data), or full — rejecting a producer that tries to register an incompatible schema.
2
This shifts format errors from runtime failures in production to deploy-time validation, which is the whole point.