Central Registry Enforcement

A schema registry is usually introduced as 'the thing that stops breaking changes'. That description skips the part an interviewer actually probes: *which two artefacts* were put side by side, and *at what moment*. ## The unit the check is scoped to A registry does not store 'the schemas of a stream'. It stores **named lineages**: a name, an ordered stack of versions beneath it, and a compatibility setting attached to that name. Every decision the gate makes is scoped to one name — a candidate document arrives under it, is compared with what is already stored under that same name, and is either appended as the next version or refused. Three consequences are worth saying out loud: - Two record types travelling over the same transport are **two lineages**, judged independently of each other. - The same record type registered under two different names is two unrelated histories. They may drift apart without the registry objecting once. - A name with no history has nothing to compare a candidate against, so the first registration under it establishes the baseline — whatever the first producer happened to ship becomes the thing every later candidate is measured against. ## What the comparison actually is The check is a **structural relation between two schema documents**. The engine walks the declared fields of the candidate and of a stored version, matches them by whatever identity the format treats as stable (a field name, a numeric tag), and asks whether a decoder built from one document can process bytes produced from the other. *Which* direction has to hold, and how many stored versions are in scope, is exactly what the configured mode selects; the definitions of those directions are a subject of their own. What matters here is the shape of the verdict: it is binary, and it is about documents. Either the candidate is stored and given an identifier, or the registration fails and names the version it breaks. There is no warning level, no score, and nothing in the verdict about your code. ## When it runs The decision is made at **registration time — before the first byte in the new shape exists**: 1. Someone edits a schema and submits it under a name. 2. The registry answers yes or no against that name's stored history. 3. Only on yes does a producer have an identifier it can write with. Because the check is a request against stored state, the identical request can be made *earlier still*, over a proposed document in a change-review step, so that a breaking edit fails a change one team is watching rather than a decoder another team is not. Same check, far cheaper failure. Moving the check earlier is the single highest-value thing a platform team does with a registry. ## What the check cannot see - **Which readers are deployed.** The registry holds no inventory of running consumers; a reader pinned to an old generated type is invisible to it. - **Hand-written decoding.** A consumer that pulls fields out by hand, or maps them into its own model, can break on an edit the registry calls safe. - **Meaning.** Changing a field's unit from minor to major currency units, or quietly reusing a field for a new purpose, is structurally identical and semantically fatal. - **Data already written.** Older bytes keep their old shape; approving a new version changes nothing about them. - **Anything outside the lineage.** A copy of the contract in a document, a partner's mirror of it, a downstream table definition. ## What a pass does and does not certify | The registry asserts | It does not assert | |---|---| | The candidate relates to this name's stored versions as the mode requires | That every deployed reader can decode the new records | | The candidate is stored and has an identifier | That readers were redeployed, or in which order | | This name's history is intact and ordered | That the change preserves what a field means | | The rule configured on this name was applied | That the same rule is configured on any other name | ## Failure shapes to recognise - A team reads a green result as a deployment plan. It is not one: ordering the producer and consumer rollouts is a decision the gate never made. - A team registers under a fresh name to escape a rejection. The scoping makes that trivially possible, and it is a common way a breaking change ships with every check green. - A team leans on the gate for a write path that never passes through it — a backfill job, an archival writer, a script producing bytes directly. The honest interview summary: a registry decides a **document-to-document** question about **one named history** at **publish time**. Everything about running processes lies outside its evidence and needs contract tests, rollout ordering and consumer-side checks alongside it.