Exercises: Data Mesh

Solutions and grading notes are in the instructor companion. Exercises marked 🧪 use code/mesh_readiness.py. Several of these ask you to argue against your own conclusion, which is the discipline this chapter is really teaching.

Warm-Up

Exercise 35.1 — Do you have the problem?

Difficulty: ★☆☆ · Time: 15 minutes

§35.1's four symptoms: a measured wait nobody defends · requests that are specifications · a central team that cannot say whether a number is right · domain teams with shadow pipelines.

  1. Score your organization on each: yes, no, or unknown.
  2. How many are "unknown"? For each, say what you would measure.
  3. §35.1 says you need at least three. Where do you land?

Exercise 35.2 — Which principles need decentralization?

Difficulty: ★☆☆ · Time: 15 minutes

For each of the four principles, answer two questions: does it require domain teams? and could your central team do it alone this quarter?

  1. Domain-oriented decentralized ownership
  2. Data as a product
  3. Self-serve data platform
  4. Federated computational governance

Then: §35.2 claims three of four are good advice at any size. Do you agree? Argue the one you disagree with most.

Exercise 35.3 — Read the readiness score

Difficulty: ★☆☆ · Time: 20 minutes · 🧪

python code/mesh_readiness.py --readiness
  1. Kestrel scores 15/32. Which principle scores worst, and by how much?
  2. §35.9 says to read the score by principle rather than in total. What does the total hide?
  3. Sort the fifteen conditions into passed and failed. What single property distinguishes the two groups?

Core

Exercise 35.4 — Measure your bottleneck

Difficulty: ★★☆ · Time: 60 minutes

§35.3's analysis costs one query against a ticket system.

  1. Export a year of intake. Categorize it — eight categories is plenty.
  2. For each: count, median wait, and could a domain team do it?
  3. Compute the delegable share and, separately, the mean wait for delegable work versus all work.
  4. Sort by wait time and look at the top three. Are they delegable?
  5. §35.3 found the delegable work already waits less than average. Does yours? If so, what does that mean for a mesh proposal?

Exercise 35.5 — Test a domain partition

Difficulty: ★★☆ · Time: 60 minutes · 🧪

  1. Propose a domain partition of your own data graph. Four or five domains.
  2. Express it in GRAPH's format and run --coupling.
  3. Report: edges crossing, and each domain's fan-out.
  4. Which tables are read by three or more domains? For each, answer §35.4's question: which domain owns it, and what is wrong with every available answer?
  5. Now redraw the boundaries to minimize crossing edges. What do the resulting domains correspond to in your organization — and do those teams exist?

Exercise 35.6 — The shared table

Difficulty: ★★☆ · Time: 30 minutes

§35.4's 📏 callout: fct_order_line is read by all four proposed domains, and all three ownership answers are bad.

  1. Restate the three bad answers in your own words.
  2. Find your equivalent table. Every organization has one.
  3. Case Study 1's merged graph has no table read by three or more domains. What changed?
  4. The mesh literature's answer is "polyseme — each domain has its own representation." When does that work, and when does it produce Chapter 30 Case Study 1?

Exercise 35.7 — Price it

Difficulty: ★★☆ · Time: 40 minutes · 🧪

python code/mesh_readiness.py --cost
  1. Run it with your domain count and engineer count.
  2. §35.10 insists the platform team does not shrink. Argue against that — construct the case where it does — then say whether you believe it.
  3. Find the headcount at which your multiple falls below 1.5. How far are you from it?
  4. Add the transition cost: how many months of paying for both? Multiply.

Exercise 35.8 — Data as a product, today

Difficulty: ★★☆ · Time: 45 minutes

§35.5 lists six properties and notes Kestrel has all six with a central team.

  1. Pick your three most-used datasets. Score each on all six.
  2. For each missing property, say what it costs to add. Most are hours.
  3. §35.5 says product framing makes "who is the consumer?" a routine question. Ask it of ten datasets. How many have none?
  4. Case Study 1 found six wholesale tables with no consumer. What did you find?

Exercise 35.9 — Self-serve, honestly costed

Difficulty: ★★☆ · Time: 45 minutes

§35.6's arithmetic: 2–5 days to build an ingestion pipeline, ~8 weeks to make it self-serve.

  1. Pick a capability your central team performs repeatedly. Count how many times a year.
  2. Estimate the do-it-yourself cost per instance and the self-serve build cost. Compute break-even.
  3. §35.6's rule: build self-serve for capabilities whose users already exist and are already asking. Does yours qualify?
  4. Case Study 1's self-serve ingestion took nine months against eight weeks and was used four times. At what usage rate would you call that a failure?

Exercise 35.10 — The shadow pipeline audit

Difficulty: ★★☆ · Time: 60 minutes

Case Study 2's shadow pipeline ran for seven months undetected.

  1. Find yours. Look for: service accounts with unexplained query patterns, scheduled exports, Google Sheets with API connectors, notebooks on a schedule, laptops.
  2. For each, measure what Case Study 2 measured: uptime, latency, time to add a metric, cost.
  3. Compare against the sanctioned equivalent. Be honest about which wins.
  4. Write the first message you would send its builder. Case Study 2's ⚠️ callout is the standard.
  5. Does anything reconcile it against a gold model? Kestrel's shadow pipeline understated revenue by 9% for seven months because nothing did.

Advanced

Exercise 35.11 — Extend the readiness model

Difficulty: ★★★ · Time: 90 minutes · 🧪

Add three to mesh_readiness.py, with self-checks:

  1. A modularity score that finds the best partition rather than scoring a proposed one. Does it agree with your org chart?
  2. A transition-cost model — the months of paying for both (§35.10).
  3. A per-domain readiness score, so you can adopt one domain at a time (§35.13).
  4. A "which domain should go first" recommendation, using fan-out and readiness.
  5. A shadow-pipeline signal: scratch tables with more than one consumer, over time.
  6. Sensitivity analysis: which single input most changes the recommendation?

Then: run #6. If one input dominates, your model is that input with extra steps — say which and whether that is a problem.

Exercise 35.12 — Argue the other side

Difficulty: ★★★ · Time: 60 minutes

This chapter concludes that Kestrel should not adopt a mesh. Write the strongest possible rebuttal.

Requirements:

  1. Use the chapter's own numbers. Do not dispute the measurements — dispute what they mean.
  2. Address the fan-out finding directly. §35.4 says no domain is autonomous; argue that autonomy is the wrong criterion.
  3. Address the cost. $810,000 buys something — say what.
  4. Address §35.3's finding that delegable work is already fast.
  5. Then evaluate your own rebuttal. Which of your four arguments is weakest, and why?

Exercise 35.13 — Design the scratch schema

Difficulty: ★★★ · Time: 60 minutes

Case Study 2's 📐 callout sanctions the pattern rather than the pipeline.

  1. Specify it for your platform: access, masking, retention, catalog tier, naming.
  2. Design the promotion path. What makes a scratch table a candidate for a real model?
  3. Design the reconciliation check. Any scratch table computing a metric that exists in gold gets compared. What threshold, and who is told?
  4. Case Study 2's check fired eleven times and twice the gold model was wrong. How does your process handle that outcome without embarrassing anyone into silence?
  5. What is your answer when someone puts a scratch table in a board report?

Exercise 35.14 — Plan an adoption you would not do

Difficulty: ★★★ · Time: 90 minutes

Even if a mesh is wrong for you, plan one properly — the exercise is in the sequencing.

  1. Use §35.13's inverted order. Give each of the four steps a duration and a cost.
  2. Which domain goes first? Justify with fan-out and readiness, not with politics.
  3. Write the contingency: what triggers reverting a domain to central ownership? (Case Study 1's is "fewer than two engineers.")
  4. §35.8's test: name the person who would approve a change to those teams' responsibilities. Have they seen a proposal like this?
  5. Write the one-page memo. Lead with the evidence, not the pattern.

Project Milestone

Exercise 35.15 — The readiness assessment

Difficulty: ★★★ · Time: 3–4 hours · 🧪

Produce the assessment Kestrel produced, for your own organization.

  1. The bottleneck analysis — a year of intake, by category, with wait times and delegable share.
  2. The coupling analysis — a proposed partition, its crossing ratio, and every domain's fan-out.
  3. The shared tables — anything read by three or more proposed domains.
  4. The readiness score, reported by principle, never in total.
  5. The cost, in headcount and dollars, including the transition period.
  6. The recommendation, in one paragraph, with the three numbers that drive it.
  7. The two ideas you will adopt regardless (§35.11), with a date.
  8. The shadow-pipeline audit (Exercise 35.10).

Deliverable: a memo of no more than two pages, plus the analysis behind it.

The recommendation must be falsifiable. "Not yet" is not a recommendation; "not until we have domain teams with engineers and a delegable-work wait above ten days" is one, and it tells the next person what changed when the answer changes — which is exactly what let Case Study 1 re-run the analysis and get a different result.