"You Build It, You Run It — You Own the Data"
In the microservices world, we accept that the Checkout Team owns the Checkout Service: its code, its database, its on-call rotation. If the Checkout Service has a bug, the Checkout Team fixes it. We don't route all bug fixes through a Central Engineering Team.
Data Mesh applies this same logic to analytical data. The team that generates the data is responsible for making it usable — not just for their own applications, but for the rest of the organization.
Old model: The Checkout Team emits transaction logs to a Kafka topic and considers their job done. The Central Data Team ingests those logs, tries to decode them, and eventually produces a checkout_events table — often months later, often with gaps and misinterpretations.
Data Mesh model: The Checkout Team is responsible for producing a clean, documented, reliable analytical dataset about checkout activity. They know what payment_method_code: 7 means. They know that orders with status: PENDING older than 24 hours are actually failed orders due to a legacy bug. They encode this knowledge into the data product itself.
How Domain Boundaries Are Drawn
Domain boundaries in Data Mesh typically mirror the bounded contexts from Domain-Driven Design (DDD). A bounded context is a logical boundary within which a specific domain model applies consistently. Common examples in an e-commerce company:
| Domain | Owns | Produces Analytical Data About |
|---|---|---|
| Checkout | Order creation, payment processing | Orders placed, payment methods, cart abandonment |
| Inventory | Stock levels, warehouse locations | Product availability, restock events |
| Shipping | Fulfillment, carrier integration | Delivery times, carrier performance, returns |
| Identity | User accounts, authentication | User registrations, login patterns |
Each domain team produces data products that expose their domain's analytical view to the rest of the organization. They do not expose raw database tables — they expose curated, documented, SLA-backed datasets.
The Organizational Implication
This principle requires a cultural shift as much as a technical one. Domain teams must accept that data ownership is part of their job, not an optional extra. This means:
- Data quality issues in a domain's output are that domain's responsibility to fix.
- Schema changes must be communicated and versioned, just like API changes.
- Domain teams need embedded data engineering skills — either by hiring or by upskilling existing engineers.
Interviewers often ask: "How is Data Mesh different from just having each team manage their own database?" The key distinction is analytical exposure. In a standard microservices architecture, each team owns their operational database but it's private — other services call APIs, not databases. In Data Mesh, each team also owns and publishes an analytical interface — a curated dataset designed for querying, joining, and reporting — not just operational APIs. The domain team is responsible for both the operational system and the analytical product derived from it.