architecture · advanced
Data Contracts and Ownership
Quick answer
A data contract specifies schema, meaning, compatibility, and SLAs for a dataset or event stream. Ownership names who can evolve it. Together they prevent silent breakages across services and analytics.
Why this matters
- Schema changes break consumers at 2am.
- "Shared DB tables" without owners become unowned liability.
- Event-driven systems need compatibility rules.
Learning objectives
- Write a minimal contract. 2. Choose compatibility mode. 3. Assign ownership. 4. Version and communicate changes. 5. Test consumers against contracts.
Explain like I am 5
If you invent a secret handshake, write the rules so friends do not get confused when you change it.
Mental model
flowchart LR
Producer --> Contract
Contract --> Consumers
Owner --> Contract
Core concepts
Semantics > types
What does `status=CLOSED` mean? Document it.Compatibility
Backward/forward rules for schemas (especially Kafka/JSON/Protobuf).Ownership
One team owns evolution; consumers get notice and dual-publish windows.SLAs
Freshness, completeness, retention for data products.Testing
Contract tests in CI for producers and critical consumers.Worked example
PaymentSettled event adds fxRate. Owner dual-publishes old/new; consumers opt in; remove old field after lag metric hits zero.
Trade-offs
| Strict contracts | No contracts |
|---|---|
| Coordination cost | Chaos |
Failure modes
| Mode | Mitigation |
|---|---|
| Silent field reuse | Additive versioning |
| Everyone writes DB | Interface + ownership |
| No changelog | RFC for breaking changes |
Interview mode
Skeleton: "Contracts + owners + compatibility + consumer tests keep distributed data evolvable."
Knowledge check
Semantics, compatibility rules, ownership, and change process
Only the database host name
Only UI colors
Nothing—types are enough always
By Shubham Jain