Viaduct: A Data‑Oriented Service Mesh for Modern SOA

In 2020, Airbnb presented Viaduct at the Hasura Enterprise GraphQL conference. Viaduct is a data‑oriented service mesh that brings a step‑wise improvement to Airbnb’s micro‑service‑based SOA (Service‑Oriented Architecture). This article explains the ideas behind Viaduct and its overall operation.

SOA Large Dependency Graph

As SOA evolves toward finer granularity, modern applications may contain thousands of tiny micro‑services that interconnect without restriction, producing extremely complex dependency graphs. Similar tangled graphs have been observed at companies such as Amazon, Netflix, and Uber. Airbnb engineers addressed this complexity by adopting a data‑oriented service mesh, which helps manage the massive number of services and advances SOA modularity.

Procedural vs. Data‑Centric Design

Historically, software design progressed from procedural (e.g., Pascal, C) to data‑centric (e.g., Simula, Clu) paradigms. SOA is traditionally procedural, and micro‑services are collections of procedural interfaces. Transforming the service mesh from a procedural to a data‑centric architecture enables SOA to evolve toward data‑oriented design.

Data‑Oriented Service Mesh

A service mesh routes service calls to the appropriate micro‑service instances. Existing industry‑standard meshes focus on remote‑procedure‑call semantics and ignore the data that composes the application. Viaduct’s vision is to replace the procedural mesh with a data‑oriented one.

Viaduct is built on graphql‑java and defines a GraphQL schema that includes:

Types and Interfaces that describe the data managed by the mesh.

Queries and Subscriptions that expose data‑access methods via abstract service entry points.

Mutations that provide data‑update methods via the same abstraction.

Using the schema, a single field such as productById(id: ID) can return a Product type. Consumers can retrieve related data in one query, e.g., productById { manufacturer } , productById { reviews } , or nested productById { reviews { author } } . The mesh resolves which micro‑services supply the required data, eliminating the need for consumers to manage explicit service dependencies.

Schema‑Centric Approach

Unlike other distributed GraphQL systems (e.g., GraphQL Modules, Apollo Federation), Viaduct treats the schema as an independent artifact. It guarantees schema consistency across multiple teams and evolves into a “Central Schema” that also defines APIs and, eventually, database schemas. This centralization improves data agility: a change to the database schema propagates automatically to client code after a single update, rather than requiring weeks of coordinated changes across many services.

Transition to Serverless

Large SOA applications often contain stateless “derived‑data” and “backend‑for‑frontend” services that transform raw data for client consumption. These stateless workloads are ideal for a serverless model. Viaduct runs derived‑field calculations in serverless cloud functions, which operate without knowledge of underlying services, simplifying the dependency graph and reducing operational overhead.

Conclusion

Viaduct, built on GraphQL, supports fine‑grained field selection, modern data‑loading techniques, circuit‑breaking, soft dependencies, and request‑level caching. It provides data observability at the field level and integrates with the rich GraphQL ecosystem (real‑time IDE, mock servers, schema visualization). Deployed in production at Airbnb since 2019, Viaduct grew from a few entities to a schema with 80 core entities handling 75% of API traffic.