Viaduct Five‑Year Review: Modernizing a Data‑Driven Service Mesh

Background and Open‑Source Release

In November 2020 Airbnb published the first article about Viaduct, a data‑driven service mesh. On 15 September 2025 the project was announced as open‑source on GitHub.

Growth Metrics

Since 2020 Viaduct has seen traffic increase by eight times. The number of teams hosting code in Viaduct doubled to more than 130, with hundreds of active developers each week. The codebase grew threefold to over 1.5 million lines (including comparable test code). Despite this growth, operational overhead remained unchanged, incident minutes were cut in half, and cost grew linearly with QPS.

Core Principles

Viaduct is guided by three enduring principles: a re‑enterable API, business logic hosted directly in Viaduct, and a central schema that connects all domains.

Central Schema

The central schema is a single, integrated GraphQL schema that links every domain within the company. More than 75 % of Viaduct requests originate internally, making Viaduct a one‑stop, data‑driven mesh that connects developers to all data and capabilities.

Hosted Business Logic

From the start, teams were encouraged to host business logic inside Viaduct, contrary to the common GraphQL best practice of keeping the server a thin layer over microservices. A serverless platform was built so developers could focus on logic rather than operations. As Katie from the Media team said, moving the Media API to Viaduct allowed them to retire independent services, reducing overhead, moving parts, and improving developer experience.

Re‑enterability

Viaduct’s developer experience centers on “re‑enterability”: hosted logic can be composed via GraphQL fragments and queries, keeping large codebases modular and avoiding classic monolith risks.

Problems with the Original Architecture

The original system evolved bottom‑up, adding capabilities in response to immediate developer needs. This resulted in many ways to accomplish the same task, a confusing developer experience for new teams, and weak, loosely defined interfaces between layers, making large‑scale changes increasingly difficult.

Viaduct Modern Initiative

To address these issues, the “Viaduct Modern” project was launched, redesigning the developer‑facing API and execution engine. A key outcome is the Tenant API, which replaces the complex old programming model (shown in the diagram) with only two mechanisms: node resolvers and field resolvers.

Tenant Modularity

Modules, called “tenants”, are owned by a single team and are not allowed to have direct code dependencies on other modules. Composition happens through GraphQL fragments and queries. An example involves a Core User team and a Messaging team:

type User implements Node {
  id: ID!
  firstName: String
  lastName: String
  ...
}

class UserResolver : Nodes.User() {
  @Inject val userClient: UserServiceClient
  @Inject val userResponseMapper: Mapper
  override suspend fun resolve(ctx: Context): User {
    val r = userClient.fetch(ctx.id)
    return userResponseMapper(r)
  }
}

extend type User {
  displayName: String @resolver
}

@Resolver("firstName lastName")
class DisplayNameResolver : UserResolvers.DisplayName() {
  override suspend fun resolve(ctx: Context): String {
    val f = ctx.objectValue.getFirstName()
    val l = ctx.objectValue.getLastName()
    return "$f ${l.first()}."
  }
}

The Messaging team can declare the displayName field without needing to know the underlying implementation details of the Core User module.

Framework Modularity

Viaduct Modern consists of three layers: the GraphQL execution engine, the Tenant API, and the hosted application code. The redesign strengthens the boundaries between these layers. The engine API uses dynamic types to represent GraphQL values, while the Tenant API provides static Kotlin classes generated for each GraphQL type, acting as a thin wrapper over the dynamic representation.

This separation allows the engine to evolve (improving latency, throughput, reliability) independently from the Tenant API (enhancing developer experience). Large changes still cross the boundary but are expected to become rarer as the new architecture stabilizes.

Gradual Migration Strategy

To avoid a “big‑bang” migration, both the Classic API and the new Modern API are built on the same engine and delivered in parallel. Teams can immediately benefit from engine performance and cost improvements while gradually adopting the Modern API for better usability.

Additional Improvements

Observability : Clear boundaries between tenant code and framework code enable more accurate ownership attribution.

Build Time : Schema‑first generation of Kotlin classes and direct bytecode generation reduce compile times as the codebase grows.

Dispatcher : A Kubernetes‑based horizontal scaling component uses shuffle sharding to isolate traffic and simplify experimental framework builds.

Open‑Source Decision

From the beginning, the intent was to open‑source Viaduct. The team believes that building software for the world improves their own quality and that contributing back is a responsibility as a major OSS consumer. The engine is production‑ready; the Modern API is still in alpha, with a small, robust core already used in high‑demand cases. Early open‑sourcing aims to grow a community that can help shape the API.

Is Viaduct Right for You?

While Viaduct has proven its ability to scale to massive graphs, the authors argue it is also suitable for teams just starting out, offering a developer‑friendly GraphQL server that can serve both super‑graph use cases and smaller experiments.