---
title: "Kafka breaking schema change rejected by Schema Registry"
description: "Confluent Schema Registry, set to BACKWARD, refuses a field type change that breaks both directions. The Kafka subject stays at v2, then a compatible v3 passes."
url: https://monedula.dev/kafka-simulator/scenarios/breaking-change-rejected/
---

# Kafka breaking schema change rejected by Schema Registry

Scenario 10.4.3 · A breaking schema change is rejected. Schema registry · Advanced · about 3 min · Apache Kafka 4.3 · Confluent Platform feature.

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 it: https://monedula.dev/kafka-simulator/playground/?scenario=10.4.3

## What 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

1. **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](https://monedula.dev/kafka-simulator/playground/?scenario=10.4.3&t=0)
2. **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](https://monedula.dev/kafka-simulator/playground/?scenario=10.4.3&t=1)
3. **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](https://monedula.dev/kafka-simulator/playground/?scenario=10.4.3&t=2)
4. **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](https://monedula.dev/kafka-simulator/playground/?scenario=10.4.3&t=3)

## 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.

## Further reading

- [Confluent documentation](https://docs.confluent.io/platform/current/schema-registry/fundamentals/schema-evolution.html)