تطور المخطط وأنماط التوافق

Real systems evolve: new fields are added, old ones deprecated. Schema evolution is the discipline of changing schemas without breaking existing producers or consumers.

Schema Registry enforces a compatibility mode on each subject. Before registering a new schema version, the registry checks it against existing versions and rejects breaking changes.

BACKWARD (the default): new consumers can read data written by the previous schema.

• You may delete fields.
• You may add fields that have a default value.

FORWARD: old consumers can read data written by the new schema.

• You may add fields.
• You may delete fields that have a default value.

FULL combines both: a change must be backward and forward compatible. The safest but most restrictive mode — only fields with defaults may be added or removed.

To add a field while keeping backward compatibility, give it a default so old data deserializes cleanly.

You can configure compatibility globally or override it per subject via the registry REST API.

These changes break compatibility:

• Adding a required field without a default.
• Renaming a field (it is treated as delete plus add).
• Changing a field's type incompatibly.

Modes like BACKWARD_TRANSITIVE check the new schema against all prior versions, not just the latest — important when consumers may lag many versions behind.

With BACKWARD compatibility, upgrade consumers first, then producers. With FORWARD, upgrade producers first. Knowing the mode dictates deployment order.

Schema evolution lets independent teams move at their own pace. Choose a compatibility mode, always add new fields with defaults, and follow the matching deployment order.

Test your understanding of compatibility modes.

You learned schema evolution and compatibility.

• BACKWARD, FORWARD, and FULL define what changes are allowed.
• Add new fields with a default to stay compatible.
• Transitive modes check against all prior versions.
• Compatibility mode dictates producer/consumer upgrade order.