How does the tolerant reader principle keep a document consumer from breaking when writers change?

## The principle "Be conservative in what you send, liberal in what you accept" is old advice from protocol design, and it applies directly to documents. Concretely, a tolerant reader: - reads **only the fields it actually uses**, by name; - **ignores unknown fields** rather than failing on them; - has a **defined behaviour for a missing field** — a default, a skip, or an explicit domain error, decided on purpose rather than by whatever the mapping layer does; - **does not assume field order or exhaustiveness**; - validates the subset it consumes, and nothing else. The payoff is that a writer can add a field without asking every consumer for permission. In a store that performs no write-time shape check, that is the difference between independent deployment and a coordinated release train. ## Where readers are accidentally intolerant Most intolerance is not a decision; it is a default nobody looked at. **Deserializers that fail on unknown properties.** Many object mappers can be configured either way. If the strict setting is on, a producer adding one field takes the consumer down — a failure that is maximally confusing because the consumer did not change. **Whole-document validation.** Running the document through a strict shape check that forbids anything not listed makes the consumer as brittle as the strictest schema anyone wrote. Validate the fields you consume, not the document. **Structural assumptions.** Asserting a field count, indexing into a document positionally, or assuming a sub-object contains exactly two keys. **Read-modify-write of the whole document.** This is the most damaging one and deserves its own section. ## The lossy write-back trap A service loads the whole document into its own type, changes one field, and writes the whole object back. Any field that the writer's type does not know about — because a newer producer added it — is not in the object, and so is not in the document that gets written. The field is silently deleted. This is insidious because both services are individually correct, nothing errors, and the loss only shows up when the *other* service next reads its own field and finds it gone. It is also intermittent: the field survives until the older service happens to touch that document. The fixes: - **Update only the fields you changed**, using a targeted field-level update, rather than replacing the document. - If you must replace the whole document, **preserve unknown fields** — many mapping layers can capture unmapped keys into a catch-all map and write them back out. - Failing both, make ownership explicit: exactly one service may replace whole documents in this collection, and everyone else does field-level updates. ## Tolerance is not a substitute for compatibility Be clear about the limit. Tolerant readers make **additive** change safe. They do nothing for: - **Renames** — the reader looks for the old name and finds nothing. From the reader's perspective a rename is a deletion plus an addition. - **Removals** — the field the reader depends on is gone, and "tolerantly" defaulting it to zero may be worse than failing loudly. - **Type changes** — a number that becomes a string will pass a presence check and then produce a wrong comparison or a parse error further in. - **Meaning changes** — the field is still there with the same type, and now means something else. This is the worst kind because no mechanical check catches it. So the rule set that actually holds a system together is: readers are tolerant, writers are conservative, and *only additive changes are made unilaterally*. Anything non-additive is a coordinated change regardless of how tolerant the readers are. ## Defaults deserve thought "Treat missing as a default" is where tolerance can hide a bug. Defaulting a missing `discountPercent` to 0 is safe. Defaulting a missing `isActive` to `true` is a decision that can enable something that was never intended. Defaulting a missing `currency` to your home currency will produce plausible, wrong money. For anything security-relevant or financial, absent should usually mean **refuse to process**, not "assume the benign value". Tolerance means not crashing on data you do not understand; it does not mean guessing at data you require. ## What interviewers listen for The strong answer states the principle in one line, gives at least one concrete intolerant pattern — ideally the lossy read-modify-write, because it shows real production experience — and then draws the boundary: tolerance buys additive freedom, nothing more. The weak answer treats "be tolerant" as a slogan and quietly implies it makes all schema change safe, or defaults every missing field without asking whether the default is a safe assumption.