Explain backward and forward compatibility for message schemas. With a schema registry, which side do you upgrade first in each case?

Backward compatible: upgrade consumers first. Forward compatible: upgrade producers first. Full compatible: any order.

Why this matters: producers and consumers are deployed separately. So for a while, old and new versions of a schema exist at the same time.

Backward compatible means consumers using the new schema can read data written with the old schema. These changes are backward compatible:

• Adding a field with a default value.
• Removing a field.

Upgrade consumers first. Then they can handle both old and new messages.

Forward compatible means consumers still using the old schema can read data written with the new schema. These changes are forward compatible:

• Adding a field.
• Removing a field that had a default value.

Upgrade producers first.

Full compatibility means both backward and forward. The deploy order does not matter.

A schema registry, such as Confluent's, stores every version of each subject's schema. It rejects a new schema that breaks the configured mode. So an incompatible change fails when you register it, not in production. Confluent's default mode is backward. The TRANSITIVE modes check a new schema against all earlier versions, not just the latest one.