This article introduces Viaduct, Airbnb's data-oriented service mesh designed to improve modularity in large microservices-based Service-Oriented Architectures (SOA). It addresses the 'spaghetti SOA' problem by shifting from procedure-oriented service meshes to a data-centric approach using GraphQL, abstracting service dependencies and simplifying data access and updates across a complex ecosystem.
Read original on Airbnb EngineeringAirbnb faced significant challenges with its growing Service-Oriented Architecture (SOA), which had evolved into a 'spaghetti SOA' characterized by massive, tangled dependency graphs among thousands of microservices. This complexity mirrored the issues of 'spaghetti code' but at the architectural level, making modifications and system evolution increasingly difficult. The core problem identified was the procedure-oriented nature of traditional microservices and service meshes, which treat each microservice as a collection of procedural endpoints, leading to explicit, tightly coupled dependencies.
Viaduct proposes a fundamental shift from procedure-oriented to data-oriented design within the service mesh. While traditional service meshes (like Istio or Linkerd) route remote procedure invocations without understanding the application's data, Viaduct organizes the mesh around data itself, utilizing GraphQL to define a unified schema across all services. This schema encapsulates types, queries, and mutations, abstracting the underlying microservice implementations.
Key Concept: Data Abstraction
In a procedure-oriented mesh, a data consumer must explicitly know and depend on multiple services to gather related data. Viaduct, as a data-oriented mesh, abstracts these service dependencies. The consumer queries the unified GraphQL graph, and Viaduct intelligently orchestrates the calls to various underlying microservices that provide the requested data fields. This significantly reduces coupling and simplifies client-side logic.
A crucial aspect of Viaduct is its 'central schema' – a single, unified GraphQL schema that defines the data graph across the entire service mesh. Unlike other distributed GraphQL approaches, Viaduct maintains this as a single artifact, facilitating collaboration while ensuring consistency. This central schema is not only used for the service mesh itself but also extends to define microservice APIs and, eventually, database schemas. This enables 'data agility,' where changes to a database schema can propagate rapidly through service APIs to client code via a single update, bypassing weeks of coordination required in traditional multi-layered SOA.
Viaduct also incorporates serverless computing to manage 'derived fields.' These are stateless transformations of raw data from lower-level services into client-appropriate formats (e.g., for 'backend-for-frontend' logic). By moving this transformational logic into serverless cloud functions that operate on the GraphQL graph, Viaduct keeps the core graph clean, reduces service complexity, and offloads operational overhead, demonstrating a practical application of serverless in a complex SOA environment.