DATA ARCHITECTUREOrg Scale

Data Mesh & Domain Ownership

How data engineers design data that lasts — pick a topic on the left and its full breakdown loads here: the mental model, ERDs and worked schemas, trade-offs, edge cases, and the decisions that separate a durable model from a fragile one.

18 min readTopics chapter readerLevel · Specialized & Applied
01 · Orientation

What You'll Master Here

Shift ownership to the domains that know the data; make each domain publish its data as a product; provide a self-serve platform; govern federally.

4 min · Topic 1 of 9

Every previous chapter was about modeling data. This one is about who owns and produces it at organizational scale. Data Mesh, coined by Zhamak Dehghani, moves data ownership from one central team to the business domains that understand the data, and asks each domain to publish its data as a product.

Work the six questions below. They are the chapter: each one has a central-team answer, a mesh answer, and a bill.

Core mental model

Shift ownership to the domains that know the data; make each domain publish its data as a product; provide a self-serve platform; govern federally.

Why it matters

As an organization grows, a single central data team becomes a bottleneck that lacks domain context, and data quality suffers. Data Mesh is the leading answer to scaling data work across many teams without descending into chaos.

domain
A business area (Orders, Payments) that owns its operational and analytical data.
data product
Data published by a domain with an owner, SLOs, docs, and a stable interface.
self-serve platform
Shared infrastructure that makes building data products easy for every domain.
federated governance
Global standards everyone follows, with local autonomy on the rest.
Halcyon Rail · a national passenger operator, 900 peopleSix business areas, one data team. Every widget in this chapter runs on this org.The chapter is not really about tables. It is about one question asked six ways: who is accountable for this data, and what have they promised?
  • Ticketingbookings, fares, refunds
  • Network Operationstimetable, actual running, delays
  • Rolling Stocktrain units, maintenance, availability
  • Stationsfootfall, concessions, accessibility
  • Customer Carecomplaints, delay-repay claims
  • Financerevenue settlement between operators
Six questions, answered by a central team and by a mesh
Read the last question firstData mesh is an organisational design with a real bill attached, not a technology you buy. Most companies should not adopt it. This chapter spends as much effort on when it does not apply as on what it is.
Common mistake

Adopting Data Mesh for a small organization with one data team. You add organizational overhead to solve a scaling problem you do not have; a central warehouse is simpler.

Better habit

Give data ownership to the domains that understand it.

Treat published data as a product, not a byproduct.

Balance domain autonomy with global, enforced standards.

The big idea

Data Mesh is primarily an organizational design, not a technology. It distributes ownership to domains and holds it together with product thinking and federated governance.

How to study this chapter

Keep one question in mind: "who is accountable for this data, and what have they promised?" Data Mesh is the answer to that at scale.

Remember this

Data Mesh decentralizes data ownership to business domains, treats data as a product, provides a self-serve platform, and governs federally, an organizational answer to scaling data work.