Scenario 10.4.1 · Subjects and versions
Confluent Schema Registry subjects and versions for Kafka
A subject (orders-value) is an ordered list of schema versions. Register compatible changes and the history grows v1 → v2 → v3.
Run this scenario in the playgroundorders-value · v1. t+0.000s
The schema registry holds one subject, orders-value - the value schema for the orders topic. It starts with a single version, v1, under the default backward compatibility. A subject is just an ordered list of versions plus the mode that gates the next registration.
Open at this step: step 1, orders-value · v1register v2 (compatible). t+1.000s
A new schema version is registered. The change is both backward- and forward-compatible (think: adding an optional field with a default), so it is accepted under backward and the subject advances to v2. No schema text is parsed - the change's compatibility is declared explicitly and the registry decides deterministically.
Open at this step: step 2, register v2 (compatible)register v3 (compatible). t+2.000s
Another compatible change appends v3. The subject's version history now reads v1 → v2 → v3. Consumers can pin a specific version while producers move forward; that ordered, append-only history is exactly what a subject tracks.
Open at this step: step 3, register v3 (compatible)What you start with
In Schema Registry, a subject (here orders-value) is a named, ordered history of schema versions for a topic. This scenario registers a sequence of compatible changes and watches the subject's version history grow v1 → v2 → v3.
Step by step
- orders-value · v1 t+0.000s The schema registry holds one subject, orders-value - the value schema for the orders topic. It starts with a single version, v1, under the default backward compatibility. A subject is just an ordered list of versions plus the mode that gates the next registration. Open at this step: step 1, orders-value · v1
- register v2 (compatible) t+1.000s A new schema version is registered. The change is both backward- and forward-compatible (think: adding an optional field with a default), so it is accepted under backward and the subject advances to v2. No schema text is parsed - the change's compatibility is declared explicitly and the registry decides deterministically. Open at this step: step 2, register v2 (compatible)
- register v3 (compatible) t+2.000s Another compatible change appends v3. The subject's version history now reads v1 → v2 → v3. Consumers can pin a specific version while producers move forward; that ordered, append-only history is exactly what a subject tracks. Open at this step: step 3, register v3 (compatible)
The takeaway
A subject is the unit of schema evolution: each compatible registration appends a new version while every prior version stays available, so old and new clients can keep reading.
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.1" title="Kafka Simulator: Subjects and versions" width="100%" height="520" style="border:1px solid #d0d0d0;border-radius:8px" loading="lazy"></iframe>
<p><a href="https://monedula.dev/kafka-simulator/scenarios/subjects-and-versions/">Confluent Schema Registry subjects and versions for Kafka</a></p>