Schema Registries for Events
You'll learn to
- -Explain what problem a schema registry solves for event-driven systems with many independent producers and consumers
- -Apply compatibility modes (backward, forward, full) to decide whether a schema change is safe to deploy
In a request-response API, a client and server negotiate compatibility at call time - if the shapes don't match, the call just fails immediately and visibly. Event-driven systems don't have that luxury: a producer publishes an event today, and a consumer might not process it until minutes, hours, or (for a replayed event log) years later - by which point the consumer's understanding of the event's schema may have drifted from what was actually published.
What a Schema Registry Does
A schema registry is a central service that stores every version of every event schema, and validates that a new schema version is actually compatible with previous versions before allowing a producer to start publishing under it - catching a breaking schema change at deploy time, before it reaches a single consumer, rather than discovering the incompatibility only when some downstream consumer fails (or silently misinterprets) the new event shape.
Compatibility Modes
- -Backward compatible: a new schema can read data written with the previous schema. Safe to deploy new CONSUMERS first.
- -Forward compatible: an old schema can read data written with the new schema. Safe to deploy new PRODUCERS first.
- -Full compatible: both backward and forward - safe to deploy producers and consumers in any order, which matters a lot when you can't guarantee every consumer upgrades before the producer starts publishing the new shape.
// v1 event
{"event_type": "order.placed", "order_id": 501, "total": 149.99}
// v2 event - backward compatible: old consumers reading this simply
// ignore the new field they don't know about
{"event_type": "order.placed", "order_id": 501, "total": 149.99, "currency": "USD"}The specific compatibility mode required depends entirely on deployment order constraints: if consumers will always be upgraded before producers start publishing a new shape, forward compatibility alone might suffice; if you can't guarantee that ordering (a common reality with many independent consumer teams, each deploying on their own schedule), full compatibility is the safer, more conservative choice.
Why This Matters More for Events Than Request-Response APIs
A REST or GraphQL incompatibility fails loudly and immediately at call time - a broken request simply returns an error right then. An incompatible event schema can fail silently and much later: a consumer might successfully deserialize an event using stale assumptions about its shape, process it incorrectly without any error at all, and the mistake surfaces only much further downstream (or never, if nobody notices) - which is exactly why proactive compatibility checking, before a producer is even allowed to publish under a new schema, matters more here than in synchronous APIs.
This is a direct extension of the schema-versioning discipline from LLD Fundamentals' database schema-versioning chapter, applied to event schemas flowing between services instead of a single database's own evolving structure.
Interview Signal is part of Pro
See a real weak answer next to a real strong one for this exact topic.
Quiz is part of Pro
Test what you just read with a short quiz, and bank the XP.
Design Schema Registry in the API Design Lab's gRPC & Event-Driven act.