Quiz: Data Mesh

Twelve questions. Answers with explanations follow — work through them first.

1. §35.1 lists four symptoms of the problem data mesh solves. Which is described as the clearest and most reliable?

• A. A queue with a wait time nobody defends
• B. Requests arriving as specifications rather than problems
• C. A central team that cannot say whether a number is right
• D. Domain teams that have built shadow pipelines

2. §35.2 observes an asymmetry among the four principles. What is it?

• A. Three of the four are vendor-neutral
• B. Only domain-oriented ownership requires decentralization; the other three are good advice at any size
• C. Only federated governance requires automation
• D. Three of the four require a platform team

3. Kestrel's intake: 386 requests a year, 61.4% delegable. Why does §35.3 conclude this argues against a mesh?

• A. 386 is too few requests to justify a reorganization
• B. The delegable work already waits less than average (3.75 vs 3.84 days), and the two slowest categories are both undelegable
• C. Domain teams would take longer
• D. The requests are mostly access-related

4. The largest single intake category at Kestrel is "why is this number wrong" — 88 requests, 23% of the total. What does the chapter say about it?

• A. It proves the central team is a bottleneck
• B. It is a question about meaning, which a catalog answers without anyone reorganizing
• C. It should be delegated first
• D. It indicates a data quality problem

5. A proposed partition has 40% of dependency edges crossing domain boundaries and every domain depending on at least one other. §35.4 concludes:

• A. The domains need better contracts
• B. You have not created autonomy — you have put a team boundary through the middle of a coordination requirement, which is worse than centralizing
• C. 40% is acceptable for a first iteration
• D. The graph needs refactoring before the domains are viable

6. gold.fct_order_line is read by all four proposed domains. Which ownership answer does §35.4 endorse?

• A. orders owns it
• B. platform owns it
• C. Each domain builds its own version
• D. None — a table four domains need means the boundary is in the wrong place

7. §35.6 compares building an ingestion pipeline (2–5 days) with making ingestion self-serve (~8 weeks). What is the deeper problem with the payback calculation?

• A. The 8-week estimate is optimistic
• B. The payback requires domain teams that do not exist yet, who would then need to learn the platform
• C. Ingestion volume is too low
• D. Self-serve tooling becomes obsolete

8. §35.10: what happens to the central team's headcount during a mesh adoption?

• A. It shrinks as work moves to domains
• B. It stays flat and changes job to platform work — which is more work, must be delivered first, and makes the central team the bottleneck for its own removal
• C. It shrinks by half
• D. It grows permanently

9. Kestrel scores 15/32 on readiness. §35.9 says the total hides the finding. What is it?

• A. Some conditions are weighted higher than others
• B. Every passed condition is something the central team built; every failed one is something a domain team would have to do
• C. Two principles score above 70%
• D. The scoring is subjective

10. §35.8's test for distinguishing a real mesh proposal from tooling dressed as architecture:

• A. Whether the platform team has capacity
• B. Whether a budget has been approved
• C. Name the person who will approve a change to four teams' responsibilities, and confirm they have seen the proposal
• D. Whether domains are in the org chart

11. §35.13 recommends adopting the four principles in reverse order. Why is domain ownership last?

• A. It is the most controversial
• B. Every earlier step is independently valuable, step 3 generates the evidence for step 4, and the failure mode becomes "a well-governed central platform" rather than teams holding responsibilities they cannot discharge
• C. It requires the most tooling
• D. It is the most expensive

12. In Case Study 2, the marketing team's shadow pipeline beat the sanctioned model on uptime, latency, and time-to-add-a-metric. What does §"Read the Plan" say the reason was?

• A. The analyst was a better engineer
• B. The gold model was poorly built
• C. Four structural advantages — the builder was the consumer, it served one consumer so it could be expedient, its correctness bar matched its decision, and it had no on-call or consequences
• D. The shadow pipeline used better tooling

---

Answers

1 — D. Shadow pipelines.

"When people route around you, the bottleneck is real." The other three are all self-reported or interpretable; a shadow pipeline is someone spending their own time to avoid you, which is behavioural evidence rather than an opinion. Case Study 2 is the worked instance, and its uncomfortable finding is that the shadow pipeline was better on every dimension its builder cared about.

2 — B. Only domain-oriented ownership requires decentralization.

Data as a product, a self-serve platform, and computational governance are all things a central team can do alone — and Chapters 17, 30, 31, and 34 have been doing them for the whole book. This asymmetry is the chapter's central point: you can adopt three-quarters of data mesh without a mesh, and those three quarters are where most of the value is at small scale.

3 — B. The delegable work is already fast, and the slow work is undelegable.

61.4% delegable sounds like a strong case until you compare wait times: 3.75 days for delegable work against 3.84 overall. Decentralizing would relieve the central team of 61% of its volume and almost none of its delay. And the two slowest categories — source ingestion at 21 days, infrastructure at 14 — are exactly the work a domain team cannot do; they are 8% of volume, most of the frustration, and a mesh does not touch them. Split your queue by wait time, not by volume, and ask who could do the slow half.

4 — B. It is a question about meaning.

23% of all intake is people asking what a number means or why two disagree, which is Chapter 30 §30.8's certified definitions and §30.9's crowd-sourced gotchas. A mesh would move those questions to domain teams, which is plausibly better; a catalog answers them without anyone moving. Notice this is the single largest category and the cheapest to address.

5 — B. A team boundary through the middle of a coordination requirement.

Any set of tables partitions into four groups; the partition tells you nothing and the edges decide. The test is autonomy: could this domain build, deploy, and change its data products without coordinating? If not, you have converted a one-person schema change into a multi-team negotiation and called it decentralization. The number to compute: for each proposed domain, how many others does it depend on?

6 — D. The boundary is in the wrong place.

Every available answer is bad: orders owning it makes orders the new central team with less capacity and no mandate; platform owning it re-centralizes the most important business table under a team whose product is infrastructure; four independent versions is Chapter 30 Case Study 1 by design. The mesh literature's polyseme answer is real and applies to a concept like "customer," not to a fact table 24 models deep in a dependency graph. Case Study 1's merged platform has no table read by three or more domains, which is what a real boundary looks like.

7 — B. The payback requires domain teams that do not exist yet.

The arithmetic alone is marginal — 33 engineer-days a year of doing it yourself against 40 days up front, breaking even in a bit over a year. But the return only begins when a domain team actually uses the tooling, and Kestrel would be building it for four teams with no data engineers, who would then need to learn it. Build self-serve for capabilities whose users already exist and are already asking, which is why Kestrel's CI and observability were worth building and source ingestion was not.

8 — B. It stays flat and changes job to something harder.

Self-serve infrastructure is more work than doing the work yourself, and it must be delivered before domain teams can act — so the central team is the bottleneck for its own removal. Kestrel estimated eighteen months of paying for both: a platform team building capabilities and domain engineers who cannot yet self-serve. That transition cost is the largest number in most proposals and is almost never in them.

9 — B. Every pass is central work; every failure is domain work.

Kestrel has built the entire supporting infrastructure of a data mesh — contracts, catalog, SLOs, automated governance — and has none of the decentralization, because the decentralization requires people who do not exist. So Kestrel is not 47% of the way to a mesh; it is 100% of the way to the parts a central team can build alone and 0% of the way to the parts that require an organization. Averaging those obscures the only decision that matters, which is why a readiness score should be read by principle and a proposal leading with a total is leading with the wrong number.

10 — C. Name the person who will approve the change to teams' responsibilities.

A mesh proposal is technical in form and organizational in substance: it requires product teams to accept a new responsibility, carry its on-call, and prioritize its consumers against their own roadmap. Nobody in a technical approval chain can compel that. If you cannot name the approver, you are proposing tooling — which may well be worth building, and should be funded and measured as tooling rather than producing the predictable outcome where the platform team builds self-serve capabilities that only the platform team uses.

11 — B. Every earlier step is independently valuable and step 3 generates the evidence.

Stop after computational governance and you have automated standards. Stop after data-as-a-product and you have products, plus the discovery of which datasets have no consumer. Stop after self-serve and you have a better central team. Only step 4 requires the organization to change, and only step 4's value depends on the previous steps. The listed order fails by giving teams responsibility they cannot discharge, damaging trust in both the platform team and the idea; the inverted order fails by leaving you where you started, only better.

12 — C. Four structural advantages, none about skill.

The builder was the consumer, so there was no requirements gap and no round trip — which is data mesh's entire thesis, demonstrated accidentally. It served one consumer, so it could make expedient choices that a product cannot. Its correctness bar matched its decision: campaign pacing tolerates 3% error, a board number does not. And it had no on-call, no SLO, and no consequences — its 99.1% "uptime" was measured by the analyst noticing. A shadow pipeline is better on the dimensions its builder cares about and worse on the ones nobody is measuring, and a response acknowledging only one of those will not be believed.