Schema Registry & contracts

BACKWARD means that a reader on the new schema must read old data. For old records, the reader fills a new field with its default, so the registry accepts it. A required (no-default) field has nothing to fill from old data, so the registry rejects it.

Source: https://docs.confluent.io/platform/current/schema-registry/fundamentals/schema-evolution.html

BACKWARD lets new-schema consumers read old-schema data. So you can upgrade consumers first, and they still read what old producers emit. FORWARD is the opposite (producers first).

Source: https://docs.confluent.io/platform/current/schema-registry/fundamentals/schema-evolution.html

The format is magic byte (0) + 4-byte schema id + Avro binary. The consumer uses the id to fetch the writer schema from the registry. The producer never embeds the schema in each message.

Source: https://docs.confluent.io/platform/current/schema-registry/fundamentals/serdes-develop/index.html

TopicNameStrategy names the subject -value (and -key for keys). RecordNameStrategy uses the fully-qualified record name instead. This allows multiple event types for each topic.

Source: https://docs.confluent.io/platform/current/schema-registry/fundamentals/serdes-develop/index.html#subject-name-strategy

FORWARD = an old reader reads new data. Adding any field is fine, because the old reader ignores it. If you remove a field that had a default, the old reader fills the missing field from the default in its own (old) schema. So this change is safe. If you remove a required field (no default), the old reader has nothing to fill it with, and the read fails.

Source: https://avro.apache.org/docs/1.12.0/specification/#schema-resolution

NONE turns off the compatibility gate entirely, so the registry accepts any schema. A rename is a drop (amount) plus an add (total) with no default link. This breaks old readers. Keep BACKWARD or FULL, so that the registry rejects the change at registration time.

Source: https://docs.confluent.io/platform/current/schema-registry/fundamentals/schema-evolution.html

Non-transitive modes compare only against the most recent registered version. The transitive variants require compatibility with every earlier version. Then a chain of steps that are each OK cannot break an old consumer that is still on version 1.

Source: https://docs.confluent.io/platform/current/schema-registry/fundamentals/schema-evolution.html

Avro resolution matches fields by name. The reader skips a field that is only in the writer schema. A field that is only in the reader schema must have a default, so that the reader can fill it. This asymmetry is exactly why 'add field with default' is backward-safe.

Source: https://avro.apache.org/docs/1.12.0/specification/#schema-resolution