Scenario 10.4.2 · Compatibility modes (backward/forward/full)
Kafka schema compatibility: BACKWARD vs FORWARD vs FULL
The mode decides what a new version may change. A forward-only change is rejected under backward, accepted under forward; full demands both directions.
Run this scenario in the playgroundorders-value · backward. t+0.000s
The subject orders-value starts at v1 under backward compatibility - Confluent's default. Backward means a consumer using the NEW schema can still read data written with the OLD one (so you may drop fields or add optional ones).
Open at this step: step 1, orders-value · backwardforward-only change rejected. t+1.000s
We try to register a change that is forward-compatible but NOT backward-compatible - e.g. adding a required field. Under backward the registry refuses it: the version history does not advance and a schema_rejected event is emitted. Same change, wrong mode.
Open at this step: step 2, forward-only change rejectedmode → forward. t+2.000s
Switch the subject's compatibility to forward. Forward means a consumer on the OLD schema can read data written with the NEW one (so you may add fields). The mode governs the NEXT registration.
Open at this step: step 3, mode → forwardsame change accepted · v2. t+3.000s
Re-registering the very same forward-compatible change now succeeds - the subject advances to v2. The change never changed; only the mode did. That is the whole point of compatibility modes.
Open at this step: step 4, same change accepted · v2mode → full. t+4.000s
Tighten the subject to full. Full demands BOTH directions: a change must be backward- AND forward-compatible to be accepted. It is the strictest of the three teaching modes.
Open at this step: step 5, mode → fullbackward-only change rejected. t+5.000s
A change that is only backward-compatible is now rejected - full needs forward compatibility too. The subject stays at v2. Full is the intersection of backward and forward.
Open at this step: step 6, backward-only change rejectedfully-compatible change · v3. t+6.000s
A change that is both backward- and forward-compatible passes even under full, advancing the subject to v3. Mode in hand: backward and forward each allow one direction; full requires both; none would allow anything.
Open at this step: step 7, fully-compatible change · v3What you start with
A subject's compatibility mode decides which schema changes Schema Registry will accept. The same forward-only change is rejected under BACKWARD compatibility but accepted under FORWARD, while FULL requires the change to be safe in both directions at once.
Step by step
- orders-value · backward t+0.000s The subject orders-value starts at v1 under backward compatibility - Confluent's default. Backward means a consumer using the NEW schema can still read data written with the OLD one (so you may drop fields or add optional ones). Open at this step: step 1, orders-value · backward
- forward-only change rejected t+1.000s We try to register a change that is forward-compatible but NOT backward-compatible - e.g. adding a required field. Under backward the registry refuses it: the version history does not advance and a schema_rejected event is emitted. Same change, wrong mode. Open at this step: step 2, forward-only change rejected
- mode → forward t+2.000s Switch the subject's compatibility to forward. Forward means a consumer on the OLD schema can read data written with the NEW one (so you may add fields). The mode governs the NEXT registration. Open at this step: step 3, mode → forward
- same change accepted · v2 t+3.000s Re-registering the very same forward-compatible change now succeeds - the subject advances to v2. The change never changed; only the mode did. That is the whole point of compatibility modes. Open at this step: step 4, same change accepted · v2
- mode → full t+4.000s Tighten the subject to full. Full demands BOTH directions: a change must be backward- AND forward-compatible to be accepted. It is the strictest of the three teaching modes. Open at this step: step 5, mode → full
- backward-only change rejected t+5.000s A change that is only backward-compatible is now rejected - full needs forward compatibility too. The subject stays at v2. Full is the intersection of backward and forward. Open at this step: step 6, backward-only change rejected
- fully-compatible change · v3 t+6.000s A change that is both backward- and forward-compatible passes even under full, advancing the subject to v3. Mode in hand: backward and forward each allow one direction; full requires both; none would allow anything. Open at this step: step 7, fully-compatible change · v3
The takeaway
Pick the compatibility mode from your rollout order: BACKWARD when consumers upgrade first, FORWARD when producers upgrade first, and FULL when either side may upgrade in any order.
Embed this scenario
Paste this into a blog post, a course page or your team's docs. The scenario plays inside your page, and the link under it points readers to this walkthrough.
<iframe src="https://monedula.dev/kafka-simulator/embed/?scenario=10.4.2" title="Kafka Simulator: Compatibility modes (backward/forward/full)" width="100%" height="520" style="border:1px solid #d0d0d0;border-radius:8px" loading="lazy"></iframe>
<p><a href="https://monedula.dev/kafka-simulator/scenarios/compatibility-modes/">Kafka schema compatibility: BACKWARD vs FORWARD vs FULL</a></p>