Viaduct 1.0 and the Future of Airbnb's Data Mesh

With Viaduct 1.0 now public, a system that was once an internal Airbnb tool has transformed into an operable data mesh built on community foundations. The intended audience includes platform engineers building company-wide data APIs, service owners looking to contribute to a shared graph, and organizations that have outgrown a single GraphQL service.

Viaduct is a GraphQL-based, data-oriented service mesh that unifies multiple data sources into a single interface. Its schema consists of Types, Queries, and Mutations, abstracting away data access and updates even when service endpoints aren't directly known.

The core idea is a structure that maintains a central schema while enabling decentralized development.

• A shared multi-tenant runtime hosts tenant modules that are developed and tested independently.
• Each team only needs to write a module directory, SDL, and resolvers.
• The platform absorbs the burden of running separate GraphQL servers, configuring routers, and infrastructure expertise.

Airbnb compares this to GraphQL Federation. While Federation distributes servers, Viaduct distributes modules, and the company notes that in large organizations, multiple Viaduct instances can also be combined as subgraphs within a federation.

For the public transition, @StableApi, @ExperimentalApi, and @InternalApi were applied, and a Kotlin binary compatibility validator was added to CI. It is now published to Maven Central, with automated releases and Dokka API documentation also provided.

The open development principles are clear as well: key architectural decisions are discussed with the community before any code is written, and the first public topic posted was GitHub's Connections RFC. Additionally, at GraphQLConf 2026 on May 20, four sessions will be introduced covering probabilistic testing, multi-tenant observability, gateway sharding, and LLM-based GraphQL mocking.