Walk me through retiring a field from an event consumed by around 40 teams, where the field is populated from a system being decommissioned in six months.

What the interviewer is testing

Whether you know that the schema registry's compatibility rules protect deserialisation, not consumers' logic, and whether you can run a deprecation that ends rather than one that accumulates. Candidates who answer "mark it optional and remove it later" have described the easy half and skipped the part that takes the six months.

The clarifying questions that change the answer

• Is history replayed? If any consumer replays from the beginning of the topic, the field must remain readable in old messages forever, and removal means "stop populating", not "stop existing". This one answer reshapes the plan.
• Is the field used in a decision or only stored? A field that feeds pricing, routing or access control has a different blast radius from one that lands in a column nobody selects.
• Can you see consumption, or only subscription? Knowing which 40 teams read the topic is easy; knowing which of them read that field is the hard part, and it decides whether you can run this in months or years.

A strong answer's arc

1. Establish the census before announcing anything. Registry subscriptions give consumer groups; field-level use requires either code search across repositories or a proxy signal. The cheapest reliable proxy is changing the value, not removing the field: populate it with a clearly wrong-but-valid value in a canary partition or a staging environment and see who complains.
2. Make it optional in the schema first, under full compatibility, so new consumers are never written against it and old messages still deserialise.
3. Announce with a date and a replacement, not a date alone. "This field goes away" starts negotiations; "this field goes away on 30 June and here is the field that carries the same meaning" starts migrations.
4. Stop populating in a staged way: one partition, then a percentage of traffic, then all. The staged stop is the test, and it is reversible in one deploy.
5. Remove from the schema only after the retention window has passed, so no live consumer can encounter a message that still carries it, unless replay requires it to stay forever.

Common weak answers

• "Use backward compatibility and delete it." Backward compatibility permits deleting an optional field, and the consumer that reads it as required breaks at runtime rather than at deserialisation. The registry cannot see that.
• "Email the teams and set a deadline." Without the census, the email reaches subscribers, not users, and the deadline slips because the first breakage is discovered by a customer.

What a strong answer adds

The organisational mechanism that makes the next one cheaper: a documented deprecation policy with a fixed minimum notice period, field-level ownership recorded in the schema, and a usage signal collected continuously rather than reconstructed per deprecation. Also the honest cost: a 40-consumer deprecation is a quarter of somebody's time, and the decision to retire a field should be made with that number visible, because sometimes the right answer is to leave the field populated with a constant and spend the quarter elsewhere.