A schema version is a distinct revision of a data schema maintained as messages evolve. In Kafka, several versions may coexist in one topic, so each message must remain traceable to the schema that defines it. section 13.1.3 section 13.1.4
A schema registry makes versioned schemas practical by:
- Storing schemas centrally as the authoritative source for a Kafka cluster. section 13.1.3
- Checking whether a proposed schema version remains compatible with older versions. section 13.1.3
- Assigning a schema ID to each message so producers and consumers can resolve its schema without transmitting the full definition. section 13.1.3 section 13.1.4
Evolving a product message
An Avro Product schema can begin with id, name, price, and stock, then gain an optional origin field in a later version. A subsequent message may also contain a category field, while its schema ID identifies the exact registered definition. This keeps messages small and lets consumers trace different product representations over time. section 13.1.4 section 13.1.3
{
"type": "record",
"name": "Product",
"namespace": "com.example.supermarket",
"fields": [
{"name": "id", "type": "string"},
{"name": "name", "type": "string"},
{"name": "price", "type": "float"},
{"name": "stock", "type": "int"},
{"name": "origin", "type": ["null", "string"], "default": null}
]
}
Inspect the Product Avro schema and its optional origin field as a concrete example of a versionable message definition. section 13.1.4
Versioning adds operational dependencies: registry outages can affect producers and consumers, manually moving schemas can change IDs, and IDs themselves carry no semantic meaning. Because Kafka stores byte arrays, client-side checks alone do not completely prevent invalid data from being produced. section 13.1.3
