A schema registry stores the contracts for events and messages and enforces compatibility when a producer publishes a new version. Without one, a producer can change a payload shape and break consumers at runtime, often silently and across teams.
Before you start
You should understand event-driven integration and schema evolution. This article covers the registry’s role; it is conceptual.
Step-by-step walkthrough
Step 1: Register the schema with each topic
Each event type has a registered schema identified by subject and version. Producers and consumers fetch the schema, and the registry is the single source of truth for the contract, which removes ambiguity about the current shape.
Step 2: Check compatibility before accepting a change
Configure a compatibility mode, such as backward compatibility, so the registry rejects a schema update that would break existing consumers. The check runs at publish or registration time, which turns a runtime failure into a build-time or deploy-time error.
Step 3: Prefer additive evolution
Add optional fields and never rename or retype in place, so old consumers keep working and new ones handle both versions. When a breaking change is unavoidable, publish a new version and run both until consumers migrate.
Worked scenario
A publisher submits a schema and the registry enforces the mode.
subject: order.created
v1: { id: string, total: number }
v2: { id: string, total: number, currency?: string } -> accepted (backward compatible)
v3: { orderId: string, total: number } -> rejected (removes id)Walk through the example
v2 adds an optional field, which old consumers ignore, so it is accepted under backward compatibility. v3 removes id and renames it, which breaks any consumer reading id, so the registry rejects it. The change is caught before it reaches production.
Common mistake
Running a registry but not enforcing compatibility, so breaking changes still ship and the registry becomes documentation. Another is treating a rename as a safe edit and discovering the break at runtime.
Verify the behavior
Register an additive schema and confirm acceptance. Submit a breaking schema and confirm rejection with a clear message. Run an old consumer against a new event and confirm it tolerates the added field.
Interview exercise
What does backward compatibility mean for an event schema?
Answer and reasoning
A new schema is backward compatible when a consumer written for the older schema can still read data produced with the new one, typically because changes are additive and new fields are optional. It means new producers can deploy before old consumers migrate. Forward compatibility is the reverse and both are enforced by the registry’s mode.
Continue learning
Compare contracts in Contract evolution and schema migration in Schema evolution. Read the Confluent schema registry documentation and try the Microservices interview questions.