When a schema registry enforces 'BACKWARD' compatibility mode on a service's request/response schema, what exactly does it check before allowing a new schema version to be registered, and how does that differ from 'FORWARD' and 'FULL' compatibility modes?

## What a schema registry does A **schema registry** is a centralized store and gatekeeper for every version of a data schema associated with a particular contract, referred to as a 'subject' (commonly one per service-interface or per message type). Its core mechanism is straightforward: whenever a team wants to register a new version of a schema, the registry runs an automated compatibility check between the new schema and the prior version(s) according to a configured compatibility mode, and it rejects the registration outright if the check fails. This moves compatibility enforcement out of code review intuition and into an automated, mechanical gate that runs the same way every time, for every schema, regardless of which team is publishing it. ## The modes, and what each one asks The specific modes encode two different questions about who reads what. | Mode | The question it puts to a new schema version | |---|---| | **BACKWARD** | 'if I upgrade my reader to the new schema, can it still correctly interpret data that was written using the old schema?' | | **FORWARD** | 'if data is written using the new schema, can a reader still running the old schema correctly interpret it?' | | **FULL** | both directions, simultaneously | **BACKWARD** compatibility asks the first of those. This is the mode you need when you deploy new consumers before old data or old producers have been fully retired - the new reader must tolerate old-shaped data. Under BACKWARD rules: - you may remove a field (a new reader simply won't look for it); - you may add a field as long as it has a default value (so old data that lacks it still parses cleanly); - but you may not add a field without a default and require it, and you generally may not change a field's type. **FORWARD** compatibility asks the opposite question. This is the mode you need when producers upgrade before all consumers have upgraded - old readers must tolerate new-shaped data. Under FORWARD rules: - you may add new fields (old readers just ignore fields they don't recognize); - but you may not remove a field that old readers still expect to find. **FULL** compatibility requires both BACKWARD and FORWARD to hold simultaneously between consecutive versions, which in practice restricts changes to the safest subset: you can add optional fields with defaults, but you generally cannot remove any field or add any field without a default, because either action would violate one direction or the other. ## Why the gate exists at all The reason this exists is that in a system with many independently-deployed producers and consumers of a shared data shape, you cannot rely on human review alone to catch every subtle incompatibility, and you cannot assume every producer and consumer upgrades atomically at the same instant - there is always a window where old and new code coexist. The registry turns 'did we just break someone' from a question answered after an incident into a question answered at registration time, before the new schema can even be published and used. ## The trade-off The trade-off is **expressiveness versus safety**. - **FULL** compatibility is the safest choice when a schema has many independent consumers you can't coordinate with directly - but it's also the most restrictive, forbidding genuinely useful cleanups like removing a field everyone has actually stopped using, unless you first prove via other means (usage telemetry, an explicit deprecation window) that it's truly safe and then do a one-time mode change or manual override. - **BACKWARD-only** is more permissive (you can remove fields freely) but assumes producers upgrade at their own pace while readers upgrade first, which fits systems where a small number of readers integrate against many possible historical data shapes. Choosing the wrong mode for your actual deployment pattern produces exactly the outage you were trying to prevent, just delayed. ## Failure modes Failure modes are usually organizational rather than technical. - A team sets the compatibility mode too loosely (e.g., NONE, meaning no check at all) to unblock a deploy under time pressure, ships an incompatible change, and only discovers the break when a consumer team's parsing starts failing in production - by which point the registry's whole value has been bypassed. - Another common failure is setting FULL compatibility on a schema that genuinely needs a breaking change, which then blocks legitimate registrations indefinitely until someone manually overrides the check or creates an entirely new subject/version namespace for a fresh major version. ## Where it shows up in practice A concrete real-world example: **Confluent Schema Registry**, widely used alongside Avro and Protobuf schemas for structured service contracts, defaults new subjects to BACKWARD compatibility and lets teams configure FORWARD, FULL, or NONE per subject; its registration API returns an explicit compatibility-check failure with the specific incompatible field named, directly in the response to a failed schema-registration call, giving the publishing team immediate, actionable feedback rather than a downstream production surprise.