DATA ENGINEERING · QUESTION 100
What is a data contract, and what should it include?
On this page
A data contract is an agreement between a data producer and its consumers about schema, meaning, quality, freshness, ownership, and change behavior. It makes expectations visible and testable at the boundary. A useful contract includes field definitions, keys, nullability, update cadence, compatibility policy, and escalation contacts; it should evolve with consumers rather than become a stale document.
LET'S MAKE IT SIMPLE
First, the idea in plain English
A downstream team often depends on another team’s table or event stream. Without an agreement, the producer can change a field or stop sending data without knowing who breaks. A contract describes what the data means, how reliable it should be, and how changes are communicated.
A USEFUL COMPARISON
Picture it this way
A restaurant supplier agrees on the ingredient, delivery schedule, quality, and what happens when a shipment changes. A data contract makes a similar agreement for schemas and data service expectations.
FOLLOW THE JOURNEY
Make producer expectations testable at the data boundary
Show ownership, schema, quality, service expectations, and change communication.
This simplified visual highlights the main relationships. In practice, the exact design depends on the requirements; Contracts must evolve without surprise breakage.
A producer publishes a versioned data contract with schema and service expectations; automated checks protect consumers and a change process coordinates updates.
How to read this visual
This simplified visual highlights the main relationships. In practice, the exact design depends on the requirements; Contracts must evolve without surprise breakage.
UNDER THE HOOD
How it works, step by step
Define ownership and meaning
Name producer, consumers, fields, keys, and business definitions.
Why it matters: Shared terminology prevents incompatible interpretations.
Set quality expectations
Specify freshness, completeness, uniqueness, and allowed ranges.
Why it matters: Consumers need measurable reliability.
Automate enforcement
Check records and compatibility against the contract.
Why it matters: Executable checks catch violations close to the source.
Manage changes
Version, notify consumers, and deprecate fields deliberately.
Why it matters: Contracts must evolve without surprise breakage.
OUTSIDE THE TEXTBOOK
A practical example
A payments team publishes an event contract defining transaction ID uniqueness, currency format, event-time semantics, delivery expectations, and schema compatibility. A warehouse consumer validates each batch and alerts the owner if freshness or required fields fail.
GO A LITTLE DEEPER
Technical details that matter
- Contracts can be encoded in schema registries, data catalogs, tests, and service-level indicators.
- Semantic meaning and timestamp conventions are as important as field types.
- A contract should identify data ownership and support escalation, not just validation rules.
MAKE A GOOD CHOICE
When is this useful?
- Decoupled teams sharing events or analytical datasets.
- Reducing breakages from schema and meaning changes.
- Making data quality expectations observable and actionable.
For a single team and short-lived dataset, code-level tests and documentation may be sufficient until independent consumers emerge.
WATCH OUT FOR
Common misunderstandings
- Documenting types but not semantics or freshness.
- Creating a contract without an owner or enforcement.
- Changing field meaning while keeping its name and type unchanged.
REAL-WORLD TRADE-OFFS
Limitations and failure cases
- Contracts cannot guarantee the producer’s source data is truthful.
- Maintaining many versions can add governance overhead.
- Consumers may need migration time and compatibility support.
WHAT TO REMEMBER
Key takeaways
- 1Contracts capture schema, meaning, quality, freshness, and ownership.
- 2Automate checks and define a compatible change process.
- 3Semantic changes need communication even when schemas look unchanged.
PRACTICE THE FOLLOW-UP
What might an interviewer ask next?
How do data contracts differ from schemas?
A schema defines structure; a contract also includes meaning, quality, freshness, ownership, and change expectations.
Who owns a data contract?
The producer owns the published data behavior, while consumers provide requirements and participate in changes; clear ownership and escalation are essential.
SAY IT OUT LOUD
How to explain this in an interview
“A data contract is a producer-consumer agreement covering schema, field meaning, quality, freshness, ownership, and change policy. I make it executable with validation and compatibility checks, and identify an owner for incidents. It should include semantic details such as timestamps and keys, because structurally valid data can still change meaning.”
Connect this question to the roadmap topic it supports.