An upstream team renames a field in the events you consume and nobody tells you. What should your pipeline have done?
5 min readUpdated 2026-08-15Target archetype: Big Tech, Enterprise Captive, Product Startup
0
Answer
Short answer
Validate every record against a declared schema at the ingestion boundary, quarantine what fails instead of dropping it, treat additive changes as safe and renames as breaking, and alert on a field that has gone all-null rather than waiting for a dashboard to look wrong.
Was this answer helpful?
Likely follow-ups
→Your loader is schema-on-read over JSON in object storage. Where do you get a contract to validate against at all?
→The rename has already been live for a week and downstream tables are wrong. What is your recovery order?
→How would you let the upstream team find out they are about to break you, before they merge?
→A field's type changes from integer to string but every value still parses. What catches that?
Why a rename is the worst shape of upstream change
An upstream outage is loud. The topic goes quiet, the freshness check fires, somebody is paged, and the data that eventually arrives is correct. A rename is the opposite: volume is normal, freshness is normal, every job succeeds, and the only symptom is that one column is now entirely null. Nothing in a conventional pipeline is watching for successful jobs producing empty columns, so the failure propagates at full speed into aggregates, features and reports, and it is discovered days later by whoever notices that a segment has stopped existing.
That asymmetry is the whole answer. You cannot prevent the upstream team from renaming a field, and you should not pretend you can. What you can do is arrange your pipeline so that an unexpected shape produces a loud, bounded, recoverable failure rather than a quiet, unbounded, retrospective one. Everything below is a mechanism for converting silence into noise.
What the contract has to pin down, beyond field names
A schema that lists field names and JSON types is the weakest useful version. The parts that break in practice are the parts a bare type declaration does not cover: which fields are required rather than merely present, what the units and currency are, what timezone a timestamp is in, what the permitted values of an enumerated field are, and which field is the key you deduplicate on. A pipeline that consumes amount without knowing whether it is pounds or pence is not protected by knowing it is a number.
The other half is the compatibility rule you agree to. Adding an optional field must be safe, because otherwise the upstream team cannot ship anything without coordinating with you and will eventually stop telling you at all. Removing a field, renaming a field, narrowing a type, tightening a required set, or changing the meaning of an existing value are all breaking, and the contract's job is to say so in a form a build can check rather than in a wiki page. A schema registry that rejects an incompatible producer at publish time is the strongest version of this, because it moves the failure to the person who caused it and to the moment they caused it.
Validate at the boundary, once
Put the validation in exactly one place: the step that turns bytes from the source into your first internal table. Downstream transformations should be allowed to assume the shape holds, because validation scattered across fifteen models is validation that disagrees with itself, and the fifteenth model is the one nobody updated.
The decision at that boundary is three-way, not two-way. A record either conforms and lands in the main table, or violates the contract and lands in a quarantine table alongside the reason and the raw payload, or the violation rate is high enough that continuing is worse than stopping. Quarantine matters more than it looks: a dropped record is unrecoverable and invisible, whereas a quarantined record is a row you can count, alert on, fix and replay once the contract question is resolved.
Loading diagram…
The branch worth arguing about in an interview is the rate threshold, because it is the difference between a pipeline that stops on one malformed record from one badly behaved client and one that cheerfully quarantines ninety percent of a day's data and reports success.
Additive by default, so that only real breaks break you
Two implementation habits do most of the work here. First, read explicitly: select the fields your contract declares, rather than ingesting whatever keys happen to be present. An unknown key then costs nothing, which is what makes additive changes genuinely safe, and it means an unexpected field is a signal you can log rather than a schema mutation in your warehouse.
Second, never overwrite a column's meaning in place. If a field's semantics change, land it as a new column and keep the old one for as long as anything reads it, exactly as you would with an API field. A migration that redefines status for history as well as for new rows silently rewrites every report ever run against it, and nobody can tell afterwards which numbers were computed under which definition.
The signal that catches a rename without a human
The detection you actually need is a per-column null-rate check against a recent baseline, evaluated as part of the load rather than as a separate nightly report. A column that has been three percent null for a month and is one hundred percent null this hour is a rename, an authentication failure at the source, or a parsing change, and it is worth stopping for in all three cases. That single check catches most of what schema validation misses, because it fires on meaning rather than on shape.
Pair it with a row-count and a freshness check per source, and with a distinct-value check on the low-cardinality fields you group by. Those three between them cover the failure classes that produce successful jobs and wrong answers: the field that vanished, the load that half ran, and the enumerated value that quietly became something your CASE expression does not mention and therefore buckets as other.
What you owe the upstream team
The honest position is that this is a two-sided contract and half of it is social. Publish which fields you consume and who is affected when they change, put a compatibility check in the producer's own pipeline so that breaking it fails their build rather than your job, and give them somewhere to announce a deprecation. A consumer that validates ruthlessly but never tells anyone what it depends on has protected itself and left the organisation with the same problem.
The goal is not a pipeline that cannot be broken by an upstream change. It is a pipeline in which the breakage is immediate, attributable, bounded to a quarantine table, and replayable once the contract question is answered.