Can adding a nullable field break a consumer?
Whether the candidate knows the difference between schema compatibility and consumer compatibility, and whether they can hold a nuanced answer under pressure to say yes or no.
The situation behind the question
Interviewers ask this because it happened to them.
A producing team wants to add an optional field to an event payload. The schema registry accepts it as a backward-compatible change and the change is scheduled for the next release.
A strong answer
Flags
Green flags
- Answers "it depends" and then immediately enumerates what it depends on rather than stopping there.
- Understands schema evolution as a property of the reader as much as of the writer.
- Names the case where the type system is satisfied and the meaning has changed, which is the failure no registry catches.
- Treats the announcement and the version as part of the change, not as courtesy.
Red flags
- "Schema changes are easy if the column still exists." Meaning breaks without the schema changing at all, and a new field can invalidate an existing aggregate while every compatibility check passes.
- Says no, flatly, because the registry marked it compatible.
- Cannot name a consumer shape that would break — positional readers, strict validators, schema inference from samples.
- Does not mention telling anyone.
Follow-ups
Where the conversation goes if the first answer holds up.
- The new field is
refunded_at. Which existing metrics are now wrong, and does any check notice? - How would you find out which consumers read this feed before shipping the change?
- What is the difference between backward and forward compatibility here, and which one does your platform actually need?