Schema compatibility rules decide whether a new schema may be registered for a subject.
BACKWARD (default in Confluent Schema Registry)
Consumers using the new schema can read data written with the old schema.
Practical meaning: you can upgrade consumers first, or more commonly: new schema must not break reading historical data.
Typical allowed changes:
- Add an optional field (with default)
- Delete a field that consumers no longer need (careful: depends on model)
FORWARD
Consumers using the old schema can read data written with the new schema.
Practical meaning: you can upgrade producers first; old consumers still work.
Typical allowed changes:
- Delete an optional field
- Add a field that old consumers will ignore (depending on format)
FULL
Satisfies both backward and forward (often FULL_TRANSITIVE across versions in stricter modes).
Safest for mixed rolling upgrades in both directions, but most restrictive on allowed changes.
BACKWARD: new consumer → can read old data (default) FORWARD: old consumer → can read new data FULL: both directions
Default to remember
Default compatibility is BACKWARD.
Interview example
Adding middle_name with a default:
- Often backward-compatible (new readers understand old records missing the field via default).
Removing a required field without care:
- Often breaks backward compatibility.
Interview tip: State the default (BACKWARD), define all three, and give one evolution example.