Build fluency in the vocabulary of validating a message's schema before it's ever published.
0 / 5 completed
1 / 5
At standup, a dev mentions a centralized service that stores every version of a message schema, like an Avro or Protobuf definition, and validates a new message against the registered schema before it's allowed to be published. What is this service called?
A schema registry is a centralized service that stores every version of a message schema and validates a new message against the registered schema before it's allowed to be published, catching a malformed or incompatible message before it ever reaches a consumer. A message broker routes and stores the published messages themselves, which is a different responsibility from validating and versioning the schema those messages must conform to. This centralized validation is what keeps every producer and consumer of a topic aligned on a single, agreed-upon message format.
2 / 5
During a design review, the team configures the registry to reject a newly registered schema version unless it's backward-compatible with the previous version, so an existing consumer won't break the moment a producer starts using the new schema. Which capability supports this?
A backward-compatibility check enforced by the registry rejects a newly registered schema version unless it remains compatible with the previous version, ensuring an existing consumer, still running the old schema definition, won't suddenly break the moment a producer starts publishing messages under the new schema. Accepting any newly registered version regardless of compatibility risks exactly that kind of breakage the moment a producer adopts it. This enforced compatibility check is what makes a schema registry a genuine safeguard rather than just a passive catalog of schema versions.
3 / 5
In a code review, a dev notices a producer service publishing a message with a field type changed from an integer to a string, without registering that change as a new schema version first. What does this represent?
This is a producer bypassing the schema registry's validation, risking an incompatible message reaching consumers unexpectedly, since changing a field's type from an integer to a string without registering that as a new schema version means the registry never had a chance to check whether the change is actually compatible with what existing consumers expect. A consumer group rebalance is an unrelated concept about partition assignment. Catching this in review matters because a field-type change is exactly the kind of incompatible schema evolution a registry is meant to prevent from silently breaking consumers.
4 / 5
An incident report shows a consumer crashed while deserializing a message, because a producer had started sending a field with a different, incompatible type than what the consumer's code expected, with no schema registry in place to catch the change beforehand. What practice would prevent this?
Adopting a schema registry that enforces a compatibility check on every new schema version ensures an incompatible field-type change is caught and rejected before a producer is ever allowed to publish under it, rather than surfacing as a consumer crash in production. Continuing to let producers publish with no registry validating compatibility is exactly what let the incompatible field type reach the consumer and crash it in this incident. This enforced compatibility check is a standard safeguard for any event-driven system where producers and consumers are deployed and evolved independently.
5 / 5
During a PR review, a teammate asks why the team adopts a schema registry with enforced compatibility checks instead of just documenting the expected message format in a shared wiki page that every team is expected to follow. What is the reasoning?
A wiki page relies on every team remembering to read it and correctly follow its documented format, which is exactly the kind of manual process that breaks down as more teams and services are involved. A schema registry mechanically rejects an incompatible schema change before it can ever reach a consumer, regardless of whether any individual engineer happened to check the documentation first. The tradeoff is the added infrastructure and workflow overhead of registering and validating a schema through the registry as part of every producer's deploy process.