ORIGINAL COMPANY-CONTEXT PRACTICE
Evolve an enterprise event contract gradually
Original practice scenario: A fictional enterprise platform changes an event field from one address string to structured address components while old consumers remain active.
Written for independent practice using company context; this is not a verified question from a company interview.
A REASONED APPROACH
Model answer.
Use an explicit compatibility window and independently test old and new readers. Changing a field's shape in place can break consumers even if the new producer considers its own output valid.
Work through it
- Publish a versioned schema or additive fields, define how legacy strings and structured values coexist, and preserve unknown fields where the protocol requires it.
- Deploy tolerant consumers first, then producers, with contract fixtures covering absent, null, legacy and new representations plus conflicting values.
- Measure remaining legacy usage, document rollback behavior and remove deprecated fields only after the supported compatibility period and evidence justify it.
Tradeoffs to discuss
- Dual representations simplify transition but can diverge; a single canonical internal form and documented precedence reduce ambiguity.
Common pitfalls
- Do not infer consumer readiness from producer deployment success.
- Schema validation alone cannot establish that the new fields retain the original business meaning.