Tolerant Reader
A consumer that ignores fields it does not recognise and depends only on what it actually needs, so a producer can add to a contract without breaking it.
The pattern that decides whether a service ecosystem can evolve. A consumer that deserialises strictly — failing on an unknown field, or binding to an exact schema — makes every additive change by the producer a breaking change, and the ecosystem freezes: nobody can add a field without a coordinated release across every consumer.
Tolerant reading means extracting the fields you need, ignoring the rest, and not depending on field order or on the absence of anything. It costs nothing and removes an entire category of release coordination.
The corollary on the producer side is the robustness principle applied deliberately: add fields rather than changing them, never repurpose an existing field's meaning, treat removal as a breaking change requiring a version, and make new fields optional with a sensible default for consumers that ignore them.
The failure worth watching for is the one strict validation is meant to catch: tolerant reading can hide a genuine integration mistake, where a field was renamed and the consumer silently reads null instead of failing loudly. The resolution is to be tolerant about unknown fields and strict about expected ones — validate that what you require is present and well-formed, and ignore everything else. Contract tests are what make that distinction enforceable rather than a matter of style.