Skip to content

SYSTEM Cited by 1 source

Viaduct

Definition

Viaduct is Airbnb's GraphQL-based data-oriented service mesh: a multi-tenant runtime that provides a single interface for accessing and interacting with data sources, used internally at Airbnb for years and released as open source 1.0 on 2026-05-13. Verbatim self-description from the announcement: "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. For years it has supported Airbnb's data infrastructure, allowing product engineers to access data efficiently and safely, while enabling service owners to decouple implementation details from the API surface." (Source: sources/2026-05-13-airbnb-viaduct-1-0-and-the-future-of-airbnbs-data-mesh)

What makes Viaduct distinctive

The wiki has three canonical implementations of decentralized GraphQL schema development; Viaduct is the third topology:

Topology Servers Modules per server Wiki canonical instance
Single-service UBFF 1 1 Zalando UBFF
Federated subgraphs many 1 Yelp CHAOS + Apollo Federation
Multi-tenant runtime (Viaduct) few many Viaduct (this page)

See: UBFF pattern + Zalando UBFF; federated- subgraph pattern + Apollo Federation; multi-tenant-runtime pattern + Viaduct (this page).

Viaduct's load-bearing framing quote: "Federation distributes development by distributing servers. Viaduct distributes development by distributing modules." (Source: sources/2026-05-13-airbnb-viaduct-1-0-and-the-future-of-airbnbs-data-mesh)

Architecture

The mesh as schema

A Viaduct service mesh is defined in terms of a GraphQL schema consisting of three primitives (verbatim from the post):

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

The repeated "abstracted from service entry points" clause is the architectural commitment: Viaduct's contract decouples the GraphQL API surface from the backend service that actually implements a given field. A type's owner can move from one backend service to another without breaking clients, because clients see only the schema-level Type / Query / Mutation, not the underlying RPC.

Tenant modules

A tenant module is the unit of contribution. Verbatim: "A team wanting to contribute simply creates a directory for their module, defines their schema definition language (SDL) and resolvers, and they are ready to serve. There is no need to set up or operate a separate GraphQL service, manage router composition, or become experts in GraphQL infrastructure. Teams focus on domain logic; the platform handles execution, scaling, and integration."

The module contract:

  • A directory in the Viaduct codebase.
  • An SDL declaring the module's Types / Queries / Mutations.
  • Resolvers implementing the contract.
  • No separate service to operate — the shared Viaduct runtime hosts the module.

This is the primitive that makes Viaduct a multi-tenant runtime rather than a federated subgraph: tenant modules don't run their own GraphQL servers; they live as code modules inside the Viaduct runtime.

Composition with Federation

Viaduct is positioned as complementary to Apollo Federation, not a replacement. "In a large organization where hundreds of teams contribute to the overall graph, a federated approach requires running hundreds of independent subgraph servers. With Viaduct, organizations can instead run a smaller number of Viaduct instances, each hosting many closely related tenant modules. Federation can then compose those instances into a larger enterprise graph."

                        Federation router
                              │
        ┌─────────────────────┼─────────────────────┐
        ▼                     ▼                     ▼
   Viaduct instance A    Viaduct instance B    Viaduct instance C
   ├─ tenant module 1    ├─ tenant module 8    ├─ tenant module 16
   ├─ tenant module 2    ├─ tenant module 9    ├─ tenant module 17
   ├─ tenant module 3    ├─ tenant module 10   ├─ tenant module 18
   └─ ...                └─ ...                └─ ...

Result: N Viaduct instances × M tenant modules per instance instead of N × M independent subgraph servers. The operational cost of running and updating servers collapses by a factor of M; the cross-organization composition still happens at the Federation router.

OSS 1.0 release substrate

The 1.0 designation is a stability commitment. Until 1.0, Viaduct evolved rapidly to meet internal needs "often with breaking changes managed through our internal monorepo tooling." Public release required:

  • @StableApi / @ExperimentalApi / @InternalApi annotations across all public surfaces — see patterns/api-stability-annotations.
  • Kotlin's binary compatibility validator running in CI to catch breaking changes before they ship — see systems/kotlin-binary-compatibility-validator.
  • Maven Central publication with automated releases.
  • Dokka-generated API documentation.
  • Open community RFC process — first instance: the Connections RFC on GitHub. Goal: "to involve the community in major architectural decisions before code is written, not after."

Operational disclosure

The 2026-05-13 post is an announcement of OSS 1.0, not an operational retrospective. No engineering throughput / latency / scale / tenant-count numbers are disclosed. The post asserts "For years it has supported Airbnb's data infrastructure" without quantification, and uses "hundreds of teams contribute to the overall graph" rhetorically when motivating the Federation-on-top-of-Viaduct topology — not as a measured count.

What is signposted as forthcoming at GraphQLConf 2026 (2026-05-20):

  • Probabilistic testing of GraphQL correctness on Viaduct (James Bellenger).
  • Multi-tenant gateway observability with built-in ownership tags, automatic alerts/dashboards, and cost-aware tracing (Vickey Yeh).
  • Sharding the gateway for blast-radius reduction (Linquan Zhang & Cetin Sahin).
  • LLM-generated mock data via @generateMock directive (Michael Rebello).

These are wiki-worthy candidates but should be ingested when the talk recordings / write-ups appear, not from teasers.

Why Viaduct exists

The post names the problem space directly: "Viaduct was built to solve a specific problem faced by most organizations that adopt GraphQL strategically: decentralized development of a central schema." It then names two sub-properties of that problem:

  • Why a central schema? "A central schema provides a single, consistent interface to the full range of an organization's data and capabilities. Instead of every client needing to know which backend service to call, they interact with one unified graph that connects all of an organization's domains. This makes APIs easier to discover, enables richer cross-domain queries, and provides a consistent place to enforce policies, observability, and schema governance."
  • Why decentralized development? "A central schema only works if it can evolve quickly. The domain experts who understand each part of the business must be able to design and implement the parts of the schema they know best. A central team cannot own everything, and shouldn't try to."

See concepts/decentralized-development-of-central-schema for the broader concept page.

Audience the post identifies

Verbatim: "Viaduct is for platform engineers building a company-wide data API, service owners who want to contribute to a shared graph without spinning up their own server, or engineering organizations that have outgrown a single GraphQL service."

Three personas, mapped to the three topologies:

  • Platform engineers building a company-wide data API — tooling/governance buyers; fits all three topologies.
  • Service owners who want to contribute to a shared graph without spinning up their own server — the Viaduct-native persona. Federation requires you to run a server; UBFF requires you to commit fields to one giant codebase; Viaduct hits the middle: contribute a module, share the runtime.
  • Engineering organizations that have outgrown a single GraphQL service — explicit anti-UBFF framing; the post positions Viaduct as the next stop after the UBFF gets too big.
  • Per-module isolation boundary — what bounds a noisy / buggy / runaway tenant module's blast radius inside the shared runtime? (Likely subject of the gateway-sharding talk.)
  • Schema composition algorithm across tenant modules — how is the global schema assembled from N module SDLs? Conflict resolution? Naming-namespace per module?
  • Per-module observability mechanism — owner-tagged metrics, automatic alerts/dashboards, cost-aware tracing. (Subject of the multi-tenant-gateway-observability talk.)
  • Migration story from Airbnb's pre-Viaduct GraphQL stack to Viaduct.
  • Probabilistic-correctness testing model — "how probabilistic testing exposes hidden bugs in complex GraphQL systems — demonstrated by Airbnb's launch of a new GraphQL engine" (subject of the Brute Force Correctness talk).

Seen in

  • sources/2026-05-13-airbnb-viaduct-1-0-and-the-future-of-airbnbs-data-mesh — first canonical wiki naming. OSS 1.0 announcement framing Viaduct as a third topology for decentralized GraphQL schema development; multi-tenant runtime + tenant-module model; complementary to Federation; full OSS-readiness substrate (@StableApi/@ExperimentalApi/@InternalApi + Kotlin binary compatibility validator + Maven Central + Dokka + community RFC process).
Last updated · 542 distilled / 1,571 read