Évolution des schémas et modes de compatibilité

Data contracts change over time — you add fields, deprecate others, rename things. Schema evolution is the discipline of changing schemas without breaking existing producers and consumers.

Producers and consumers often deploy at different times. A new producer might emit a v2 schema while old consumers still expect v1.

Without rules, that mismatch causes deserialization failures in production.

Backward: new schema can read data written with the old schema.

• Safe changes: delete a field, add a field with a default.
• Upgrade consumers first.

Forward: old schema can read data written with the new schema.

• Safe changes: add a field, delete a field that had a default.
• Upgrade producers first.

Full requires both backward and forward compatibility at once.

• Only changes safe in both directions are allowed (add/remove fields with defaults).
• Producers and consumers can be upgraded in any order.

Each mode has a transitive version (BACKWARD_TRANSITIVE, etc.).

Non-transitive checks only against the latest schema; transitive checks against all prior versions — stronger guarantees, more constraints.

Compatibility is configured per subject (or globally) via the Schema Registry REST API.

Adding a field with a default keeps old data readable under BACKWARD mode.

The registry can check a candidate schema against the current one before you commit it.

Changes that almost always break compatibility:

• Renaming a field (treated as delete + add).
• Changing a field's type incompatibly.
• Adding a required field with no default.

For these, create a new subject/topic version instead.

Rules of thumb:

• BACKWARD (default) when you upgrade consumers first.
• FORWARD when producers lead.
• FULL for independently deployed teams.
• Use transitive variants for long-lived, replayable topics.

You learned schema evolution and compatibility modes.

• BACKWARD: new reads old, upgrade consumers first.
• FORWARD: old reads new, upgrade producers first.
• FULL: both, any order.
• Transitive variants check all prior versions; renames and required no-default fields break compatibility.