Kafka Schema Registry Config Generator
A Schema Registry configuration, with the compatibility level explained as the thing it decides: which side of a change you deploy first.
schema-registry.properties
updates as you typeCommon mistakes
These are the ones that fail silently. The config is accepted, nothing raises an error, and the consequence arrives later.
Setting compatibility globally and forgetting subject overrides
A subject-level setting silently overrides the global one, so a change rejected in one subject and accepted in another looks inconsistent.
Instead:Check the subject level before debugging the global.
Using the default subject naming strategy for multi-type topics
TopicNameStrategy allows one schema per topic. A topic carrying several event types needs RecordNameStrategy or TopicRecordNameStrategy.
Instead:Choose the strategy up front. Changing it later strands the existing subjects.
Leaving the registry unauthenticated
It holds the schemas for every topic and, with write access, an attacker can register an incompatible schema and break every producer.
Instead:Secure it like any other production service.
Compatibility is a statement about deployment order
The direction is not about which schema is newer. It is about which side can be updated first.
BACKWARD means consumers first
A new schema can read data written with the old one, so you update consumers, then producers. It permits deleting a field and adding an optional one, and forbids adding a required field. It is the default and it is right most of the time, because consumers usually outnumber producers and can be updated more gradually.
FORWARD means producers first
The old schema can read data written with the new one, so producers go first and consumers follow. It permits adding a required field and forbids deleting one, which is the exact mirror of BACKWARD. Choosing FORWARD and deploying consumers first produces a deserialization failure in production after a deploy that passed every test in CI.
The transitive variants check every version, not just the last
Non-transitive compatibility only compares the new schema with the immediately previous one, which means a chain of individually compatible changes can be collectively incompatible. That matters when a consumer reads a long backlog written across several schema generations, which is exactly what happens after an outage.
The registry's database is one Kafka topic
Every schema lives in the _schemas topic, compacted. A message written with the Confluent wire format carries only a four byte schema id, so losing that topic makes every such message permanently undecodable. It deserves the replication factor of your most important topic, because in a sense it is.
auto.register.schemas lets a producer change the contract
It is on by default, which means any producer registers a new schema on first use. One misconfigured producer can therefore change the contract for every consumer of that topic. Off, with schema registration as an explicit step in a pipeline, is the difference between a governed contract and a shared mutable variable.