When many services share a topic, an unmanaged JSON payload is a breaking change waiting to happen. The Schema Registry stores Avro schemas and rejects changes that would break existing consumers.
Define a schema
Avro schemas are explicit about fields, types, and defaults, which is what makes compatibility checks possible.
{
"type": "record",
"name": "Order",
"fields": [
{ "name": "id", "type": "string" },
{ "name": "total", "type": "double" },
{ "name": "note", "type": ["null", "string"], "default": null }
]
}Compatibility modes
Set backward compatibility so new consumers can read old data; adding a field with a default is safe, removing a required one is not.
curl -X PUT http://localhost:8081/config/orders-value \
-d '{"compatibility": "BACKWARD"}'Takeaways
- The registry stores schemas by subject and version, not the messages themselves.
- Producers send a schema ID; consumers fetch the matching schema to decode.
- Add fields with defaults to evolve safely; never repurpose an existing field.
Adopt a compatibility policy early — retrofitting one onto a topic already full of ad-hoc payloads is painful.