Handling Kafka schema evolution means changing the structure of the records written to a topic over time without breaking consumers that haven't upgraded yet, typically managed through a schema registry and backward-compatible changes.
Key Points: • A Schema Registry (e.g. Confluent Schema Registry) stores and versions schemas centrally, and producers/consumers reference schema IDs rather than embedding full schemas in every message. • Prefer backward-compatible changes — such as adding optional fields with defaults — so consumers on the old schema can still read messages written with the new one. • Configure the registry's compatibility mode (BACKWARD, FORWARD, or FULL) to enforce the desired evolution policy and reject incompatible schema registrations. • Producers validate outgoing messages against the latest registered schema, and consumers validate incoming messages against the schema version referenced in each record. • Roll out schema changes gradually: update the schema first, deploy consumers that can handle both old and new formats, then update producers.
Example: Adding an optional "discountCode" field with a default value to an "OrderCreated" schema lets old consumers ignore the new field entirely while new consumers can read it, so both producer and consumer versions can coexist during a rolling deployment.
Interview Tip: A concise interview answer is:
"I'd manage schema evolution through a Schema Registry with backward compatibility enforced, so new fields are added as optional with sensible defaults, letting old consumers keep working against the new schema while producers and consumers are upgraded independently and gradually."