Schema evolution is the controlled modification of a data contract while producers, consumers, and stored records continue to interoperate. Schema Registry centralizes schemas, validates changes, and provides a shared source of truth that Kafka clients can discover through serializers and deserializers. section 3.2.1 section 3.9
A producer-aware serializer retrieves a schema over HTTP, caches it locally, serializes the record, and sends bytes to Kafka. A consumer deserializer retrieves the matching schema when needed, caches it, and reconstructs the record. The broker remains independent of the data format. section 3.2.1 section 3.0
Control a schema change through its subject and compatibility policy:
- Use a subject as the namespace that scopes schema evolution and determines which existing schema is compared with the proposed version. section 3.3
- Select TopicNameStrategy, RecordNameStrategy, or TopicRecordNameStrategy to define the scope of compatibility checks. section 3.3
- Apply backward, forward, or full compatibility; use the transitive variants when compatibility must hold across all versions rather than only the immediate predecessor. section 3.9
- Disable automatic registration in production when schema publication should be controlled explicitly with auto.register.schemas=false. section 3.3
Evolving an Avro event
An AvroAvenger schema can remove a hero's civilian name and add a list of powers. Schema Registry compares the new schema with the subject's existing version before accepting the change. Generated Java classes, producer serializers, and consumer deserializers then keep the event pipeline aligned. section 3.3 section 3.2.9
Figure 3.3 Schema Registry ensures consistent data format between producers and consumers.
Use the architecture diagram to trace schema discovery, local caching, serialization, Kafka transport, deserialization, and schema storage. section 3.2.1
