Schema Registry

Picture this: 50 microservices communicate through Kafka. Service A publishes "OrderPlaced" events. Services B, C, and D consume them. Service A ships a release that renames customerId to customer_id. Services B, C, and D break in production at 2 AM because they expected the old field name.

This happens constantly in organizations without schema governance. LinkedIn's streaming infrastructure team reported that uncoordinated schema changes were their number one source of data pipeline outages before they adopted a schema registry. Netflix documented a similar pattern: producer teams would evolve event schemas without realizing they had 12 downstream consumers depending on every field.

A schema registry is a centralized store for all message schemas. Producers register their schema before publishing. Consumers fetch the schema before deserializing. And critically, the registry enforces compatibility rules. Before a new schema version is accepted, the registry checks it against previous versions. Incompatible changes are rejected at registration time, not at 2 AM in production.

Confluent Schema Registry (for Kafka) is the most widely deployed, handling over 10 trillion messages per day across its cloud customers. AWS Glue Schema Registry integrates with MSK and Kinesis. Apicurio Registry is the open-source alternative with no vendor lock-in. Azure Schema Registry plugs into Event Hubs. The concept is identical: centralize schema governance so breaking changes are caught before they reach production.

Producer flow:

1. Define a schema in Avro, Protobuf, or JSON Schema
2. Register the schema with the registry (gets back a numeric schema ID)
3. Serialize the message using the schema
4. Prepend the schema ID (4 bytes) to the binary message payload
5. Publish to Kafka

Consumer flow:

1. Read the message from Kafka
2. Extract the schema ID from the first 4 bytes
3. Fetch the schema definition from the registry (cached locally after first fetch)
4. Deserialize the binary payload using the fetched schema

The schema ID adds 5 bytes of overhead per message (1 magic byte + 4 ID bytes). Negligible. But those 5 bytes mean any consumer can decode any message from any producer at any point in schema evolution, using the exact schema that produced it.

Serialization format matters. Avro is the most common choice for Kafka because its schema is separate from the data, enabling the registry pattern naturally. Protobuf works well too, with the schema compiled from .proto files. JSON Schema is the least efficient (larger payloads, no binary encoding) but the most familiar to teams coming from REST APIs. The JSON Schema lesson runs a closed schema, an added optional field and a newly required one against old and new messages, so you can see which change breaks which reader.