Opening scenario
Your platform team runs 40 microservices, half of them producing or consuming Kafka events. Last quarter a producer team added a new required field to the order-created event. Three downstream consumers crashed in production. They crashed because they were deserializing old binary payloads with the new schema and getting parse errors. The fix was a roll-out coordination doc, a Slack thread, and two hours of partial outage.
Today a new team is about to ship a similar change. They've read about Schema Registry. But they aren't sure what problem it actually solves. They also aren't sure what discipline it imposes. They ask you: "Will adopting Schema Registry prevent this from happening again? Or do we still need the Slack thread?"
To answer, you must understand three things. First, what Schema Registry stores. Second, what compatibility checks it runs. Third, what runtime guarantees it actually provides. You must also know which problems are still on the team.
In the full tutorial
- What problem does Schema Registry actually solve?
- How does the wire format actually work?
- What does "compatibility mode" enforce, and what does it not?
- What's the subject naming strategy, and why does it matter?
- What happens at deployment time when a schema changes?
- What can go wrong, and how do you debug it?
- Sample wire-flow code (Avro + Confluent registry)
- Closing: When to reach for this