Data Mesh Guide

Data mesh architecture diagram: four layers that fit on one page

By the engineer who builds Datadef, from client work on data platforms · Reviewed August 21, 2026

A data mesh diagram that works has four layers and nothing else: domain zones, the data products inside them with their output ports, the self-serve platform band underneath, and the governance plane across the top. Every mesh diagram that fails does the same thing, which is drawing every table and every pipeline until the picture becomes a warehouse diagram with the word mesh at the top.

Try it free
7 min readFor architects who have to show the mesh to people who will not read the doc

See it as a diagram

Everything below, as a diagram you can edit. Describe yours and see it in seconds.

277/2000• 3 credits left
Try:

No account needed · Editable canvas, not a picture

The four layers, and what goes in each

Domain zones. One zone per domain, named after the business capability, not the source system. Four to eight zones is the readable range, and the same ceiling applies inside a zone. Datadef own Terraform pipeline enforces exactly that on generated diagrams: a zone is created for a module holding two or more nodes, and no zone is allowed past eight nodes before its tail collapses into a named supporting-resources node. Past eight domains, group them and draw the group.

Data products with their ports. Inside each zone, one node per published product, labelled with the port technology rather than the table name: orders (Snowflake table), orders (Kafka topic). Do not draw the internal staging models, they are implementation detail the reader cannot act on.

Platform band. A horizontal band under the zones listing capabilities, not vendors alone: storage, orchestration, catalog registration, access control, observability. It communicates that every domain is standing on the same floor, which is the point of the third principle.

Governance plane. A band across the top holding the global decisions: classification vocabulary, shared identifiers, naming rules, minimum quality bar, plus the policy checks that enforce them. Two or three lines, not a policy library.

The arrows are consumption, not ingestion

This is the detail that separates a mesh diagram from a warehouse diagram. Arrows run from an output port of one domain to a consuming domain, directly. Nothing routes through a central node, because there is no central node in the target architecture. If your diagram has every arrow converging on one box, you have drawn a hub and spoke and labelled it a mesh.

Label the edges with what is actually consumed, at the port level: "orders topic, daily" beats an unlabelled line. Labelled edges are also what makes the diagram reviewable, because a domain lead can point at one and say that dependency does not exist any more.

Leave off ingestion from operational systems unless the diagram is specifically about one domain. Source systems belong on a domain-level diagram, one per zone, where they are the subject rather than clutter.

Drawing it, and keeping it from going stale

Datadef generates the canvas from a description in one pass: zones for domains, nodes for products, labelled edges for consumption, and real service icons rather than grey rectangles. The registry holds 2,093 ids, 624 Azure, 438 AWS and 226 GCP among them, plus the data tools a mesh diagram actually needs: Snowflake, BigQuery, Kafka, dbt, Airflow, Databricks, Postgres. It stays editable afterwards, so a domain lead can move a product between zones without redrawing.

Keeping it true is the harder half. Connect the repositories that describe the mesh, the dbt project or the Terraform that provisions each domain account, with read-only access on GitHub, GitLab, or Azure DevOps, choose the branch or tag, and the diagram plus its architecture.md regenerate on a daily sync. A node dragged more than twelve pixels from where the previous sync left it is recorded as hand-placed and restored after the redraw, so a re-sync updates the picture rather than reshuffling it. A sync whose parsed structure hashes to the same fingerprint as the previous run stops before generation, so a commit that only reworded a description produces no new picture.

Declaring domain and owner in the model metadata makes the grouping explicit for every reader downstream, and it is worth doing regardless of tooling.

# dbt: make the domain boundary explicit in the project itself
models:
  - name: orders_fct
    description: Orders published by the checkout domain.
    meta:
      domain: checkout
      data_product: orders
      owner: [email protected]
      output_ports:
        - snowflake://analytics/checkout/orders_fct
        - kafka://checkout.orders.v2
      contract: contracts/checkout/orders.odcs.yaml

Where the diagram has to live

A mesh diagram that lives in a slide deck is consulted twice and then forgotten. Put it where the decisions happen: one markdown line renders it as a live embed in the platform README, a Notion page, or a Confluence space, and the image follows the canvas, so the version people see is the current one. Readers need no account.

For the export path, PNG and JPEG are available from the canvas when a static copy is needed for a review pack. Export it last, from the same canvas the embed points at, so the file in the pack and the live picture cannot disagree.

One page per audience

Keep the four-layer mesh view for leadership and platform reviews, and give each domain its own diagram showing source systems, transformations, and ports. Trying to serve both audiences on one canvas is what produces the unreadable version. See what belongs in pipeline documentation.

FAQ

What should a data mesh architecture diagram show?

Four layers: domain zones named after business capabilities, the data products published inside each zone with their output port technologies, a self-serve platform band listing shared capabilities, and a governance plane holding the global rules. Arrows show consumption between domains, not ingestion from source systems.

How is a data mesh diagram different from a data warehouse diagram?

The arrows. In a warehouse diagram everything converges on one central store. In a mesh diagram, consumption arrows run directly from one domain output port to another consuming domain, with no central hub in the path. A mesh diagram whose arrows all converge is really a hub-and-spoke diagram.

How many domains can you fit on one mesh diagram?

Four to eight zones stay readable, and the same ceiling applies to the nodes inside one zone. Beyond that, group related domains and draw the group on the overview, then give each group its own page. The overview is for orientation; detail belongs on per-domain diagrams.

Should individual tables appear on the mesh diagram?

No. Show published data products and their output ports. Internal staging and intermediate models are implementation detail that a reader of the mesh view cannot act on, and including them turns the diagram back into a pipeline map with the word mesh at the top. Per-domain diagrams are where the internal models belong, one page each.

How do you keep a mesh diagram current as domains change?

Generate it from the repositories that define the mesh rather than redrawing it. Connecting the dbt project or the Terraform for each domain account with read-only access lets the diagram and its architecture document regenerate on a daily sync, and embedding it as a live image means every README shows the current version.