What are the compatibility modes in Confluent Schema Registry, and at a high level what does each one allow?
answer
- BACKWARD = read old with new = consumers first
- FORWARD = read new with old = producers first
- FULL = both directions, only optional add/remove
- NONE = no checks; _TRANSITIVE = all versions
- BACKWARD is the default
basics
~20 sSchema Registry has BACKWARD (default), FORWARD, FULL, NONE, and a _TRANSITIVE variant of each. They control what schema changes are allowed: BACKWARD lets new consumers read old data, FORWARD lets old consumers read new data, FULL means both, NONE disables checks.
solid answer
~40 sConfluent Schema Registry enforces a compatibility mode per subject. The core modes are BACKWARD (the default), FORWARD, FULL, and NONE, each with a _TRANSITIVE variant. BACKWARD means a consumer using the new schema can read data written with the previous schema, so you can add optional fields and delete fields. FORWARD means a consumer using the old schema can read data written with the new schema, so you can add fields and delete optional fields. FULL means both directions hold. NONE disables all checks. The non-transitive variants only check the immediately previous schema version; the _TRANSITIVE variants check the new schema against every prior registered version of the subject. The mode determines the safe upgrade order: BACKWARD means upgrade consumers first, FORWARD means upgrade producers first.
go deeper
Memorize the five names and the one-line meaning of each, plus that BACKWARD is the default.
Be able to map each mode to allowed field changes and the safe upgrade order.
Explain transitive vs non-transitive and when long retention forces TRANSITIVE.
Frame mode choice as an org-wide governance decision tied to deployment topology and topic retention.
## What problem this solves In Kafka, producers serialize records and consumers deserialize them. If they use different versions of a schema (e.g. an Avro record definition), deserialization can fail or silently lose data. **Confluent Schema Registry** is a service that stores schemas, assigns each a global ID, and validates that a new schema version is *compatible* with existing ones before allowing registration. Compatibility is configured per **subject** (by default `<topic>-value` or `<topic>-key`), or globally as a default. ## Key terms - **Reader schema**: the schema the consumer uses to deserialize. - **Writer schema**: the schema the producer used to serialize the bytes. - **Compatible**: data written with one schema can be read with another without error. ## The modes - **BACKWARD** (the default): the *new* schema can read data written with the *previous* schema. Concretely you may **delete fields** and **add optional fields** (fields with a default). New consumers (reader = new schema) can still read old records (writer = old schema). Upgrade **consumers first**. - **FORWARD**: the *previous* schema can read data written with the *new* schema. You may **add fields** and **delete optional fields**. Old consumers (reader = old schema) can read new records (writer = new schema). Upgrade **producers first**. - **FULL**: both BACKWARD and FORWARD hold simultaneously. You may only **add or remove optional fields** (fields with defaults). Upgrade order is unconstrained. - **NONE**: no checks at all — any change registers. Use only when you manage compatibility out-of-band. ## Transitive variants Each mode has a **_TRANSITIVE** form: `BACKWARD_TRANSITIVE`, `FORWARD_TRANSITIVE`, `FULL_TRANSITIVE`. The non-transitive (default) form checks the candidate schema **only against the latest registered version**. The transitive form checks it against **all previously registered versions** of the subject. Transitive matters when old data with old schemas may still live in a topic (e.g. long retention or compacted topics) and you need any reader to handle any historical writer. ## Mechanism on register When you (or the serializer with auto-registration) call `POST /subjects/<subject>/versions`, the registry runs the compatibility check for the subject's mode against the relevant prior version(s). If incompatible it returns HTTP 409 and refuses registration; the producer then fails. You can also test without registering via `POST /compatibility/subjects/<subject>/versions/latest`. ## Edge cases - Default-value rules differ between Avro, Protobuf, and JSON Schema; for Avro, a field must have a `default` to be safely added under BACKWARD or removed under FORWARD. - Changing a field's type, or renaming without an **alias**, generally breaks compatibility. - The mode applies to the subject's history, not to a single message — it constrains the *evolution graph*, not individual records.
- Which mode is the default in Confluent Schema Registry?BACKWARD. It is chosen because the most common rollout is to upgrade consumers first so they can read both old and new data.
- What does the _TRANSITIVE suffix change?It checks the new schema against ALL previously registered versions of the subject, not just the latest one — important when old-schema data still exists in the topic.
saying these in an interview costs you the question
- Saying FORWARD is the default (BACKWARD is).
- Claiming BACKWARD means 'old consumers read new data' — that is FORWARD.
- Thinking NONE still does minimal validation; it does zero checks.
- Confusing reader/writer: BACKWARD = NEW reader reads OLD writer.