Schema Registry

In request-response integration, a breaking change fails immediately and visibly. In event-driven integration it fails later, elsewhere, in a consumer the producer has never heard of — and possibly during a replay months afterwards. The registry is what restores the fast feedback.

Its function is to hold the schema for each subject, assign versions, and enforce a compatibility policy at registration time. A producer attempting to register an incompatible schema is rejected by its own client library before a single message is published, which moves the failure from production to development.

The operational benefits beyond compatibility: messages carry a small schema identifier rather than the full schema, which reduces payload size materially on high-volume topics; consumers can fetch the writer's schema to deserialise correctly; and the registry becomes a discoverable catalogue of what events exist and what they contain.

The choices that need deciding deliberately: which compatibility mode per subject — full compatibility is the safe default for topics with unknown consumers, and stricter than necessary for a topic with one consumer you control; and the subject naming strategy, which determines whether a topic may carry multiple event types.

The failure to guard against is a registry that becomes a single point of failure in the data path. Clients should cache schemas locally and continue operating when the registry is unavailable, which most implementations support and not all deployments configure.