Scenario 10.4.3 · A breaking schema change is rejected
Kafka breaking schema change rejected by Schema Registry
A change that breaks both directions is refused under backward compatibility - the subject stays at its last good version. A compatible change still goes through.
Run this scenario in the playgroundorders-value · v1. t+0.000s
The subject orders-value starts at v1 under backward compatibility. The registry is the guardrail between producers and consumers: it only lets a new version through if it will not break readers of the data already on the topic.
Open at this step: step 1, orders-value · v1register v2 (compatible). t+1.000s
A safe, backward-compatible change is registered and accepted: the subject advances to v2. So far the contract evolves cleanly.
Open at this step: step 2, register v2 (compatible)breaking change REJECTED. t+2.000s
Now a breaking change - incompatible in BOTH directions (e.g. changing a field's type) - is attempted. Under backward the registry refuses it. The subject stays at v2 and a schema_rejected event records the refusal: the producer's contract is protected from an unsafe evolution.
Open at this step: step 3, breaking change REJECTEDcompatible change · v3. t+3.000s
A subsequent compatible change still goes through, advancing the subject to v3. The gate blocked only the unsafe registration - compatible evolution continues unimpeded. That selective rejection is what keeps a long-lived topic readable.
Open at this step: step 4, compatible change · v3What you start with
Schema Registry enforces compatibility at registration time. Under BACKWARD compatibility a change that breaks readers is rejected, so the subject stays pinned at its last good version; a subsequent compatible change is then accepted normally.
Step by step
- orders-value · v1 t+0.000s The subject orders-value starts at v1 under backward compatibility. The registry is the guardrail between producers and consumers: it only lets a new version through if it will not break readers of the data already on the topic. Open at this step: step 1, orders-value · v1
- register v2 (compatible) t+1.000s A safe, backward-compatible change is registered and accepted: the subject advances to v2. So far the contract evolves cleanly. Open at this step: step 2, register v2 (compatible)
- breaking change REJECTED t+2.000s Now a breaking change - incompatible in BOTH directions (e.g. changing a field's type) - is attempted. Under backward the registry refuses it. The subject stays at v2 and a schema_rejected event records the refusal: the producer's contract is protected from an unsafe evolution. Open at this step: step 3, breaking change REJECTED
- compatible change · v3 t+3.000s A subsequent compatible change still goes through, advancing the subject to v3. The gate blocked only the unsafe registration - compatible evolution continues unimpeded. That selective rejection is what keeps a long-lived topic readable. Open at this step: step 4, compatible change · v3
The takeaway
Registry-side compatibility checks stop an incompatible schema before it ever reaches a topic, turning a would-be runtime deserialization failure into a clear registration error.
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.3" title="Kafka Simulator: A breaking schema change is rejected" width="100%" height="520" style="border:1px solid #d0d0d0;border-radius:8px" loading="lazy"></iframe>
<p><a href="https://monedula.dev/kafka-simulator/scenarios/breaking-change-rejected/">Kafka breaking schema change rejected by Schema Registry</a></p>