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.
3
What the interviewer is probing.
What the interviewer is probing.
4
1. "What counts as a breaking change?" *Probing:* the precision. *Stalls:* "A big change."
*Moves up:* removing or renaming a field, changing its type or cardinality, adding a required
request field, or tightening validation.
1. "What counts as a breaking change?"
5
2. "What is the tolerant reader principle?" *Probing:* the practical rule. *Stalls:* "Nothing."
*Moves up:* clients ignore fields they do not recognise, which is what lets a server add fields
without breaking anyone.
2. "What is the tolerant reader principle?"
6
3. "How do you rename a field safely?" *Probing:* the technique. *Stalls:* "Just rename it."
*Moves up:* add the new one, populate both, migrate clients, then remove the old after the
deprecation window.
3. "How do you rename a field safely?"
7
4. "How do you know whether a change broke someone?" *Probing:* the method. *Stalls:* "They
complain." *Moves up:* consumer-driven contract tests plus usage telemetry per field, so you know
who still reads what.
4. "How do you know whether a change broke someone?"