evolution
Backward Compatibility
Ship API improvements without breaking existing clients — by being a strict producer and a lenient consumer.
Backward compatibility is the practice of evolving an API so that clients written against the old version keep working unchanged. It is what lets you avoid a disruptive version bump for most changes, and it rests on a guiding maxim often called Postel's Law: be conservative in what you send, and liberal in what you accept. A strict producer and a lenient consumer can each change independently without breaking the other.
A car that'll accept any reasonable key shape — still recognizes the old key after the lock is upgraded.
Key Concepts
1
In practice, certain changes are safe and others are not. Additive changes are generally compatible: adding a new optional field to a response, adding a new endpoint, or accepting a new optional request parameter does not break a client that does not know about it — provided the client ignores unknown fields rather than rejecting them, which is why lenient parsing matters. Breaking changes are the ones that force a version bump: removing or renaming a field, changing a field's type or its meaning, making a previously optional parameter required, tightening validation, or changing default behaviour. The subtle traps are semantic rather than structural — repurposing an existing field, or changing the units or format of a value, looks compatible on the wire but silently breaks clients that interpreted the old meaning. Treating responses as append-only and never removing or repurposing what you have already published is the core habit.
2
The expertise interviewers reward is classifying a proposed change as compatible or breaking before shipping it, and designing defensively so that compatibility is easy to maintain: clients that tolerate unknown fields, servers that supply sensible defaults for new optional inputs, and contracts that grow by addition. When a genuinely breaking change is unavoidable, that is the signal to reach for versioning and a deprecation plan rather than slipping the change into the existing contract and hoping no one notices.