05.03 · Concept
Schema Registry and Event Contracts
Define an event schema with compatibility rules that prevents breaking downstream streaming consumers.
No video curated for this lesson yet
This lesson is written, ordered and part of the path - the video slot is the only thing still open. We are working through Everything Data lesson by lesson; 55 of 85 have their video so far.
The written notes below cover this idea in full - you lose nothing by reading instead of watching.
A schema registry makes stream events behave like stable APIs, with explicit field names, types, optionality and versioned contracts. Compatibility rules stop producers from publishing changes that older or newer consumers cannot read, reducing surprise failures when services deploy independently across a real-time data platform.
What this lesson answers
- how does a schema registry prevent breaking consumers
- what makes an event schema backward compatible
- how should streaming event contracts evolve safely
Notes
A schema registry is the shared source of truth for the shape of events moving through a streaming system. Instead of treating Kafka messages or other stream events as loosely defined blobs, producers publish events that conform to a registered schema, and consumers read those events with confidence about field names, types, and meaning. This turns an event into a contract: the producer agrees to emit data in a known structure, and downstream consumers build their logic against that structure.
Common questions
- What is a schema registry in a streaming system?
- A schema registry is the central place where event formats are defined and versioned. Producers validate messages against registered schemas, while consumers use those schemas to decode events consistently. It replaces informal assumptions about payload shape with an explicit contract that can be checked as the system changes.
- What schema changes are safe for streaming consumers?
- Safe changes usually preserve what existing consumers expect. Adding an optional field with a sensible default is typically safe. Removing required fields, changing a field type, or renaming a field without a migration path can break consumers because independently deployed services may still depend on the old contract.
- Why treat events as long-lived APIs?
- Stream events often outlive the producing service code and are consumed by teams the producer does not directly coordinate with. Designing them as APIs encourages stable names, explicit meaning, careful optionality and planned evolution. That makes changes reviewable and reduces production failures caused by incompatible payloads.
Short definition: what is Schema Registry and Event Contracts?