Skip to content

CONCEPT Cited by 1 source

Data-oriented service mesh

Definition

A data-oriented service mesh is a single GraphQL-shaped interface for accessing and interacting with any backing data source within an organization, where the mesh topology is the schema graph rather than the network proxy graph. The term is load-bearing in the announcement of Viaduct, which calls itself one verbatim: "Viaduct is Airbnb's data-oriented service mesh, a GraphQL-based system that provides a single interface for accessing and interacting with any data source." (Source: sources/2026-05-13-airbnb-viaduct-1-0-and-the-future-of-airbnbs-data-mesh)

A data-oriented service mesh is defined in terms of three GraphQL primitives (verbatim from the same source):

  • Types (and interfaces) — describing data managed within the mesh.
  • Queries (and subscriptions) — providing means to access that data, abstracted from the service entry points that provide the data.
  • Mutations — providing ways to update data, again abstracted from service entry points.

The repeated "abstracted from service entry points" clause is the architectural commitment that distinguishes a data-oriented mesh from a service mesh in the Envoy/Istio sense.

Disambiguation: data-oriented vs RPC-oriented service mesh

The term "service mesh" is overloaded between two distinct architectures that should not be conflated. The RPC-oriented mesh is canonically realised by Envoy / Istio; the data-oriented mesh is canonically realised by Viaduct.

Property RPC-oriented service mesh Data-oriented service mesh
Mesh substrate Network L7 proxies (sidecar/central) GraphQL schema (Types/Queries/Mutations)
Unit of routing RPC call (HTTP / gRPC / TCP) GraphQL field resolution
Mesh topology Proxy graph (one proxy per service) Schema graph (Type → resolver → backend)
Decoupling axis Cross-cutting concerns (mTLS, retries, traffic shaping, observability) Data-source identity (a Type's backend can change without client breakage)
Tenant unit A service A schema module / Type / Query / Mutation
Failure unit A proxy hop A resolver call
Telemetry layer Per-RPC spans, mesh-level metrics Per-field tracing, schema-level usage

Both meshes provide "unified governance, observability, and policy" but at different altitudes. An organization can run both: the data-oriented mesh handles the API-shape contract, while the RPC-oriented mesh handles the network-layer call between Viaduct and its backends.

This is the same disambiguation the wiki applies to "data mesh" (analytics-platform shape vs API-access shape): see concepts/data-mesh for the analytics version.

Why the data-oriented framing matters

Two architectural consequences fall out of treating the schema as the mesh:

  • Backend ownership is not API ownership. A Type owner can migrate the resolver from one backend service to another without breaking clients, because clients see only the schema-level Type / Query / Mutation. This is the "abstracted from service entry points" invariant.
  • Cross-domain queries are first-class. A single GraphQL query can traverse Types owned by different teams / modules / services, with the mesh handling the fan-out. RPC- oriented meshes don't compose cross-service queries; they only route the calls.

Three concrete topologies that realise it

A data-oriented service mesh can be implemented in three runtime topologies, all of which share the schema-as-mesh framing:

  • Single-service / single-module — UBFF (Zalando shape). One server, one schema, one runtime.
  • Many servers / many subgraphs — Federation (Yelp CHAOS shape). Many servers, each with one subgraph; composed at a router.
  • Few runtimes / many modules per runtime — Viaduct (this post's contribution). A small number of multi-tenant runtimes, each hosting many tenant modules; optionally composed at a Federation router.

The mesh-as-schema framing is what unifies them. The patterns/graphql-unified-api-platform pattern is the umbrella; this concept names what makes that pattern a "mesh" rather than just a gateway.

Adjacent concepts

  • concepts/data-mesh — the analytics-platform sense: domain-owned data products + a global catalog + an exchange protocol (Mercedes-Benz on Unity Catalog + Delta Sharing as the wiki's canonical instance). Different altitude from the data-oriented service mesh: the analytics data mesh is about cross-team batch / analytical data exchange; the data-oriented service mesh is about cross-team online / transactional API access. They share the decentralised ownership + centralised governance posture.
  • concepts/decentralized-development-of-central-schema — the problem space the data-oriented service mesh addresses.
  • concepts/unified-graph-principled-graphql — the discipline that says all data-oriented mesh topologies should expose one schema graph, not many.

Seen in

Last updated · 542 distilled / 1,571 read