Taming Service-Oriented Architecture Using A Data-Oriented Service Mesh

Airbnb’s Viaduct rethinks the service mesh as a data-oriented layer rather than a network for routing procedural service calls. Built on GraphQL, it presents a unified data graph that hides microservice dependencies from consumers and improves modularity in large SOAs. The central schema can also coordinate service APIs, database models, and serverless data transformations, making system-wide changes more agile.

The Problem with Large SOAs

• Modern organizations may operate thousands of microservices connected through highly tangled dependency graphs.
• These graphs resemble “spaghetti code” at the service level:
  • Changes become difficult to plan.
  • Teams must coordinate across many service boundaries.
  • Consumers often depend directly on multiple underlying services.
• Airbnb argues that microservice architectures need stronger organizing principles and technical mechanisms for enforcing modularity.

From Procedure-Oriented to Data-Oriented Design

• Traditional procedural design groups procedures into modules with public APIs and hidden implementation details.
• Data-oriented design instead organizes software around encapsulated data objects and the methods that operate on them.
• Microservices have largely returned SOA to a procedural model:
  • Each service exposes collections of remote procedural endpoints.
  • Consumers must know which services provide the data they need.
• Viaduct applies data-oriented principles to the service mesh itself.

Viaduct’s GraphQL Data Mesh

• Viaduct defines the mesh through a GraphQL schema containing:
  • Types and interfaces representing managed data.
  • Queries and subscriptions for reading data.
  • Mutations for updating data.
• The schema forms a single graph spanning data owned by many microservices.
• A consumer can navigate related data through one query, such as:
  • productById { manufacturer }
  • productById { reviews }
  • productById { reviews { author } }
• Viaduct determines which services provide each requested field.
• This hides service dependencies from consumers and prevents every client from building its own cross-service orchestration logic.

The Central Schema

• Unlike distributed GraphQL approaches that split schemas across modules or federated services, Viaduct treats the schema as one central artifact.
• Airbnb uses schema-management primitives to let multiple teams collaborate while preserving a unified model.
• Portions of the central schema can define individual microservice APIs.
• Airbnb ultimately aims to use the same schema to define database structures.
• This could improve “data agility”:
  • Database changes would no longer need manual translation through several API layers.
  • A single schema update could propagate changes from storage through services to clients.
  • Cross-team coordination and delivery times could be reduced.

Serverless Derived Fields

• Many SOAs contain stateless services that transform backend data for particular clients or presentation layers.
• Viaduct supports derived fields computed by serverless cloud functions.
• These functions operate on the graph without needing direct knowledge of the underlying microservices.
• Moving transformation logic into stateless containers can:
  • Reduce the number of services.
  • Lower operational overhead.
  • Keep the core service graph simpler.

Implementation and Operational Features

• Viaduct is built on graphql-java.
• It supports fine-grained field selection through GraphQL selection sets.
• It uses data-loading techniques and an intra-request cache.
• Reliability features include short-circuiting and soft dependencies.
• Field-level observability shows which services consume particular data.
• Its GraphQL interface enables use of established open-source tooling and interactive development tools.

Viaduct’s practical recommendation is to place a unified data schema at the center of the architecture, allowing the mesh—not individual consumers—to manage service composition. This can make large SOAs more modular, easier to evolve, and better suited to serverless execution.