Schema Registry · Approach

01 · Develop the design

Plan the design

Register canonical immutable schema documents with explicit subject/version relationships and a restricted reader/writer compatibility model. Atomic version-checked registration prevents concurrent changes bypassing policy.

Stage 1

Restrict the language first

This exercise supports named primitive fields, required/optional markers and explicit defaults, with readers ignoring unknown fields. It does not claim to implement every real serialization format.

Stage 2

Test both directions

New-reader/old-writer and old-reader/new-writer checks answer different rollout questions. State whether comparison is to latest or all retained versions.

Stage 3

Make registration race safe

Two writers can pass checks against the same old version. Recheck expected subject version when committing the new immutable schema.

02 · Work through the method

Step-by-step approach

Define the supported record schema and reader defaults/unknown-field behavior. Validate and canonicalize schemas, excluding only semantically irrelevant formatting under a versioned canonicalization rule.
For backward checks, ensure the new reader can obtain every required field from each selected old writer or a valid default. For forward checks invert reader/writer roles; reject unsupported type changes conservatively.
Under a subject transaction verify expected latest version and compatibility against the configured latest/transitive set. Insert or reuse an immutable schema ID and append the new subject version.
Events carry schema ID. Consumers cache immutable schemas by ID with bounded memory; unknown IDs fail explicitly or retry registry lookup rather than decode under the latest schema. Authorization scopes subjects and administrative policy changes.

03 · Justify the choices

Why this approach works

What does backward compatibility mean in this exercise?

The new reader can read data from the selected older writer schemas

Compatibility direction describes a reader/writer relationship, not an undirected similarity measure.

How should a new required field without a default affect old data?

Reject backward compatibility under this record-language policy

An old payload cannot provide a required field that the new reader cannot default.

How should event payloads identify their contract?

Carry an immutable registered schema ID

A consumer must resolve the exact writer schema rather than whichever version is current.

04 · Plan the evidence

Validation strategy

A required added field without a default fails backward checks.
Reader/writer inversion changes forward/backward outcomes as specified.
Concurrent registrations cannot both skip the latest subject version.
Immutable IDs resolve old events and semantic changes remain visibly outside structural guarantees.

Trade-offs to explain

Structural compatibility does not prove semantic compatibility, such as changed units in an unchanged numeric field.
Transitive checks protect older consumers but constrain schema evolution more than latest-only checks.
Real serialization formats have their own compatibility rules; this restricted teaching language must not be presented as a substitute.