Skip to content

CONCEPT Cited by 1 source

Schema registry

A schema registry is a centralized, versioned store of data contracts — typically event / message / record schemas — used as the single source of truth for the shape, type, and semantics of data flowing across service boundaries. It turns implicit, per-team contracts into explicit, discoverable, and auditable artifacts.

Core responsibilities

  • Single source of truth for event/message definitions across teams.
  • Versioning — schemas evolve; the registry retains previous versions; publishers and subscribers negotiate which version they produce/consume.
  • Validation — publishers can validate outbound events; subscribers can validate inbound events.
  • Compatibility enforcement — backward / forward / full rules that gate schema changes at PR / build time (prevent silent contract breaks).
  • Deprecation paths — structured removal of fields / events, with lead times communicated to consumers.
  • Discovery — a browsable catalog of every event type + its publishers + its subscribers (the "who produces what, who consumes what" map that ad-hoc pub/sub systems famously lack).
  • Audit trails — every schema change attributed, reviewed, and reversible.

Registry vs validation — a load-bearing distinction

"EventBridge provides developers with tools to implement validation using external solutions or custom application code, it currently does not include native schema validation capabilities." — Amazon Key team, 2026-02-04 (sources/2026-02-04-aws-amazon-key-eventbridge-event-driven-architecture)

A schema registry that stores schemas and a schema validation layer that enforces them are separable capabilities. AWS EventBridge provides the former (+ schema discovery from live traffic) but not the latter; for teams with strict validation requirements this forces a build-on-top choice between a centralized validation service and patterns/client-side-schema-validation. The Amazon Key team explicitly chose client-side validation after evaluating both — the centralized option would have added a network hop + its own scaling problem.

Design axes

  • Format: JSON Schema (Draft-04 used by Amazon Key's registry), Avro (Confluent Schema Registry canonical), Protobuf, OpenAPI.
  • Storage: dedicated microservice vs built into the event-bus control plane.
  • Code generation: runtime lookups vs build-time code bindings. Build-time bindings give type-safe event constructors + publish/ subscribe interfaces at the developer ergonomics level.
  • Governance model: self-service schema PRs vs gatekept by a central team.
  • Integration surface: IDE plugin, CLI, CI hook, runtime library.

Why "loose schemas" is an organisational cost

Without a schema registry, event contracts exist only in the consumer code that parses them. Consequences:

  • Breaking changes "almost impossible to implement" safely — publishers can't know whether a consumer relies on a field.
  • No collaboration surface for schema modifications across teams.
  • No place for publishers to discover whether an event is valid before it hits the bus.
  • Semantic context (inheritance, composition, required-vs-optional) is lost; every consumer re-infers it.

This is exactly the gap Amazon Key's custom repository was built to close.

Seen in

Last updated · 200 distilled / 1,178 read