The data-mesh capstone — start here
The map — what the capstone builds, the reading order, and a link to each page in the set. Start here.
This is the reading guide for the data-mesh capstone — the map of what the set covers and the order to read it in. The capstone takes every building block from the main tutorial and assembles them into one working system: a data mesh of services that own their data as products, talk over a deliberate mix of protocols, evolve their contracts safely, scale to demand, and stay observable throughout.
The set is written to be read straight through the first time — each page picks up where the last left off, and the cross-references assume you’ve seen the earlier material. If you’re returning to find one thing, the descriptions below will point you at the right page.
How the set is organized
The nine pages fall into three movements. The conceptual grounding (pages 1–2) establishes what a data mesh is and why Kubernetes is a natural substrate for one. The implementation (pages 3–8) builds the system: the services and their data products, the contracts and catalog that make them discoverable, the data planes they communicate over, progressive delivery with mutual TLS, elastic scaling and recovery, and the observability to see it all. The closing page (9) steps back to the failure modes — the conceptual and organizational anti-patterns that derail data-mesh efforts even when the technology is sound.
The pages
- 1 · Concepts & principles — What a data mesh is, operational versus analytical data, and Dehghani’s four principles. The grounding before any commands.
- 2 · Kubernetes as the substrate — Why the four principles map cleanly onto namespaces, operators, RBAC, and platform primitives, and the shape of the system you’ll build.
- 3 · Services & data products — The anatomy of a data product, the five domain services plus the gateway, and the order-service template the others follow.
- 4 · Contracts & the catalog — Versioned contracts in a registry, the runtime-versus-discovery distinction, and why a catalog is a mesh requirement rather than an add-on.
- 5 · The data planes — The synchronous read layer (REST, gRPC, a GraphQL gateway) and the asynchronous event backbone — and why the capstone uses all of them.
- 6 · Progressive delivery & mTLS — Evolving a contract in the open with a v1→v2 canary, mTLS for free, and the decision to mesh selectively rather than namespace-wide.
- 7 · Elastic & resilient — Scaling to demand and to zero with KEDA, and the cloud-native recoverability the platform provides.
- 8 · Observability — Metrics, distributed traces across products, and the live view of traffic moving through the mesh.
- 9 · Anti-patterns — The conceptual and organizational ways data-mesh efforts go wrong, drawn from the literature, so you can recognize them early.
If you have time for only a few
Read concepts for the vocabulary, contracts & the catalog for the idea that holds a mesh together, and anti-patterns for what to avoid. Those three cover the shape of the thing without the full implementation depth.
Where the capstone continues
This capstone grew into two standalone reference architectures that take the same data mesh further:
- Data mesh reference architecture — Python (repo) is a fork of this capstone, broken out for its own audience. It carries the same services and domain, with its own workshop chapters, demos and an OpenShift Local appendix.
- Data mesh reference architecture — Quarkus (repo) builds the same mesh with Quarkus and Camel.
Use this capstone to see how §1–§12 fit together on one minikube profile; use the reference architectures when the data mesh itself is the subject.
Start with concepts & principles.