Data Mesh & Domain Ownership

Earlier chapters showed how to model data. This chapter asks a different question. Who owns the data, and who answers when it breaks?

Picture the shop as a company that grows. Orders, customers, payments and marketing each get their own team. A domain is one business area, such as orders or customers.

One central data team can no longer know all four areas. Data mesh is one answer to that. Zhamak Dehghani wrote about the idea in 2019: each domain owns its data and shares it as a product.

A data contract is a written promise about a table. Data Contracts, Schema Evolution & Governance covers contracts in full. A key is a column that finds a row, such as customer_id.

What you will learn

1. Why one central team stops working as a company grows.
2. The four principles of data mesh.
3. How to draw a domain boundary, and what a data product is.
4. How two domains join their data, and how a shared rule keeps the join right.
5. Which teams do what, and when a mesh is the wrong choice.

A small company can use one central data team. It loads data from every system, builds the tables, and answers every question.

As the company grows, two things go wrong. The queue of requests gets long. And the team does not know what the data in each system really means.

Here is a small case. The orders team renames the column amount to total_amount, and tells nobody. The central team runs its revenue report:

-- The central team's report, written last month
SELECT SUM(amount) AS paid_revenue
FROM orders
WHERE status = 'paid';

The rename cost the orders team nothing. It cost the central team a broken dashboard. More central engineers would not help, because they would still sit far from the orders team.

Melvin Conway noticed in 1968 that a system copies the shape of the teams that build it. One central team makes one central system. Data mesh changes the team shape first.

Data mesh has four principles. They work as a set. Take one away, and a known problem comes back.

Here are the four, with what each one means and what breaks without it:

Principle 1 hands the data to the teams that know it. Principles 2, 3 and 4 stop the new problems this causes: data nobody can use, extra cost, and teams that drift apart.

Federated means the rules come from a group of domain and platform people. Computational means a program checks the rules. The next sections take each principle in turn.

A domain owns its data. So where does one domain end and the next begin? Look for a word that changes meaning.

Eric Evans called the area inside such a boundary a bounded context, in his 2003 book Domain-Driven Design. Inside the boundary, each word has one meaning.

Take the word customer. Ask three domains how many customers the shop has. The marketing domain and its table are made up for this chapter:

SELECT 'orders' AS domain, COUNT(DISTINCT customer_id) AS customers
FROM orders
UNION ALL
SELECT 'customers', COUNT(*) FROM customers
UNION ALL
SELECT 'marketing', COUNT(*) FROM marketing_contacts;

The word customer has three meanings here. Give each its own name, such as buyer, shop customer and contact. Then nobody argues about one number.

A good boundary passes two checks. One team can own everything inside it from start to end. And most changes stay inside it.

A data product is data that one team shares with a promise to its users. It is more than a published table.

Writers on mesh list common qualities of a product. The exact words differ between sources. Here is one version, with the shop's customers domain as the example:

A goal such as "loaded by 06:00 every day" is called an SLO, a service level objective. Here is the customers product written down, goals included. The format is made up, and real tools use other formats:

product: customers.shop_customers
owner: customers-team
output_table: shop_customers_current
freshness_slo: loaded every day by 06:00
columns:
  customer_id: whole number, unique, never NULL
  name: text, personal data
  country: two-letter code, NULL means not known

A promise needs a check. This query tests the promise "customer_id is unique and never NULL" on the published table:

SELECT COUNT(*)                    AS row_count,
       COUNT(DISTINCT customer_id) AS distinct_ids,
       COUNT(*) - COUNT(customer_id) AS null_ids
FROM shop_customers_current;

This is a data contract in small form. Which changes are breaking, and how to version a contract, are in Data Contracts, Schema Evolution & Governance. This chapter does not repeat them.

A mesh has many products, and many questions need two of them. A join works only if both products use the same key.

Here is revenue by country. Orders owns paid orders, and customers owns the country. The shared key is customer_id:

SELECT c.country, SUM(o.amount) AS paid_revenue
FROM orders_paid AS o
JOIN shop_customers_current AS c
  ON c.customer_id = o.customer_id
GROUP BY c.country
ORDER BY paid_revenue DESC;

This is the country today, not the country at order time. Asha lived in IN when she placed order 101. Modeling For Consumption: The BI Handoff explains the difference.

Now the payments domain joins in. It is made up, and it numbers its own accounts, so account 3 means Asha. A person joins account_no to customer_id, because both look like ids:

SELECT c.name, SUM(p.amount) AS paid
FROM payments AS p
JOIN shop_customers_current AS c
  ON c.customer_id = p.account_no
GROUP BY c.name
ORDER BY paid DESC;

The numbers matched, but the meaning did not. The fix is one shared rule: a product that talks about a person carries the customers domain's customer_id. The next section shows how to enforce it.

Governance means shared rules. In a mesh, a small group makes them, with people from the domain teams and the platform team. That is the "federated" part.

The rules are checked by code when a team publishes a product. That is the "computational" part. Nobody waits for a meeting.

Keep the global rules few. A rule is global only if one team can break another team by ignoring it. Test each rule that way:

Access control and personal data are in the data pipeline chapter Security, Governance & Compliance. Here is a check for the key rule. It runs when payments publishes, and finds rows with an unknown customer_id:

SELECT p.payment_id, p.customer_id
FROM payments AS p
LEFT JOIN shop_customers_current AS c
  ON c.customer_id = p.customer_id
WHERE c.customer_id IS NULL;

A mesh has three kinds of group. Each has one main job:

The platform gives a domain team the parts it would otherwise build alone. A short list:

• A template to create a new data product.
• A catalog where every product is listed.
• The automatic checks from the last section.
• Access control, so only the right people read a product.
• Monitoring of freshness and quality, as in Data Observability & Monitoring.

Without a platform, every team must build these parts alone. The work moves to new people. It does not get smaller.

A central warehouse holds clean tables for reports, and one team runs it. A lake holds raw files, and one team often runs that too. Compare that with a mesh:

Neither side wins every row. Mesh gains speed and context, and it pays with more work on rules and keys. A company can also mix the two: a central team for shared data, and domain teams for the rest.

An anti-pattern is a common mistake that looks like a good idea. Here are four common ones. Each comes from a principle that was skipped:

1. Many owners, no platform. Each team builds its own tools, so the work only moves.
2. Owner in name only. A person is named, but has no time, no goals and no authority.
3. Different keys. Payments numbered accounts its own way, so joins matched the wrong people.
4. Different definitions. Two teams use the word revenue for two numbers.

Take the last one. Two domains can use the word revenue in different ways. The marketing numbers are made up:

The gap is 60.00, the refunded order 103. A shared rule fixes it: one name, one definition and one owner for each metric.

When does mesh fit?

This is a judgement, not a law. Mesh may fit when all of these are true:

• The company has many domains, each with its own team.
• The central team has a long queue, and breaks often come from changes it did not hear about.
• Domain teams have engineers who can own data.
• The company can pay for a platform team.

Mesh is probably the wrong choice when one small team serves the whole company. That team can keep a central warehouse, and write down its definitions.

Six ideas to keep:

1. One central team stops working when it cannot see the changes other teams make.
2. The four principles are domain ownership, data as a product, a self-serve platform and federated computational governance.
3. Draw a domain boundary where a word changes meaning. Customers counted 4, 5 and 7 for that reason.
4. A data product has an owner, goals, a description and shared keys, and a check proves the promise.
5. A shared rule on customer_id keeps a cross-domain join right. A publish check enforces the rule.
6. Mesh costs teams, a platform and rules. It fits many domains, and it is usually the wrong choice for one small team.

Check yourself

• Why did the payments join give Asha's 65.00 to Carla, and the total still looked right?
• Name the four principles. Which one hands the data to the domain teams, and which problem does each of the other three stop?
• Why can the counts 4, 5 and 7 all be right?

Each exercise opens a canvas for an entity-relationship diagram (ERD). You draw the tables, and the review checks them against sample rows.

Start at the top. These are hard, so the last two are optional.