Skip to content

CONCEPT Cited by 1 source

Decentralized development of a central schema

Definition

Decentralized development of a central schema is the problem of letting many teams contribute to one shared API schema — without forcing every change to flow through a central platform team — while still preserving the schema's coherence, stability, and governance. The phrase appears verbatim in Airbnb's Viaduct 1.0 announcement as the load-bearing problem statement: "Viaduct was built to solve a specific problem faced by most organizations that adopt GraphQL strategically: decentralized development of a central schema." (Source: sources/2026-05-13-airbnb-viaduct-1-0-and-the-future-of-airbnbs-data-mesh)

This concept page names the problem, independent of any specific topology that solves it. Three concrete solutions appear elsewhere on the wiki:

The two sub-properties

The problem decomposes into two opposing pulls (verbatim from the Viaduct post):

Why a central schema?

"A central schema provides a single, consistent interface to the full range of an organization's data and capabilities. Instead of every client needing to know which backend service to call, they interact with one unified graph that connects all of an organization's domains. This makes APIs easier to discover, enables richer cross-domain queries, and provides a consistent place to enforce policies, observability, and schema governance."

Five forces this gives:

  1. Discoverability — clients have one place to look for data.
  2. Cross-domain queries — one query crosses team boundaries.
  3. Consistent policy enforcement — auth, rate-limiting, and redaction live in one place.
  4. Consistent observability — usage metrics, deprecation tracking, and error semantics share a substrate.
  5. Consistent schema governance — naming, type-design, and evolution rules can be enforced uniformly.

Why decentralized development?

"A central schema only works if it can evolve quickly. The domain experts who understand each part of the business must be able to design and implement the parts of the schema they know best. A central team cannot own everything, and shouldn't try to. The challenge is giving teams autonomy over their own domain contributions while preserving the coherence and stability of the shared schema."

Three forces:

  1. Domain expertise lives at the edge. The team that owns the booking system understands Booking better than any central platform team.
  2. Central-team scaling fails. As schema surface grows, funnelling every change through one team becomes the organisation's release-velocity bottleneck.
  3. Cohort-of-experts is wrong fit. GraphQL infrastructure is a specialty; making every domain team build that expertise distributes the cost N-times over.

The fundamental tension

The central-vs-decentralized pair pulls in opposite directions:

    Central schema                 Decentralized development
    ───────────────                 ─────────────────────────
    discoverability                 domain expertise at edge
    cross-domain queries            no central-team bottleneck
    consistent policy               teams ship independently
    one observability               one team's blast radius is
    one governance                    bounded

Topology choice is a trade across this axis:

  • UBFF (single service) maximises consistency (one repo, one deploy, one schema source-of-truth) but pays in autonomy (every team rides the same release train; a bad resolver in domain X can degrade domain Y). See patterns/unified-graphql-backend-for-frontend.
  • Federation (many subgraphs) maximises autonomy (each team owns and deploys its subgraph independently) but pays in operational cost (every team runs and operates a GraphQL server) + governance complexity (cross-subgraph coherence requires Federation-specific tooling). See patterns/federated-graphql-subgraph-per-domain.
  • Viaduct (multi-tenant runtime) trades down the Federation autonomy axis (modules share a release train within a runtime) in exchange for collapsing the operational cost (no per-team server) — a middle position. See patterns/multi-tenant-graphql-runtime.

Why this concept matters separately from the topologies

The problem-vs-solution split lets the wiki:

  • Compare topologies on common ground — the same problem, three different runtime substrates.
  • Identify when to switch. UBFF that's growing past one team's release cadence is a candidate for Viaduct or Federation. Federation with too many small subgraph servers is a candidate for consolidation onto Viaduct instances. The topology choice is reversible; the schema-as-graph commitment is not.
  • Locate adjacent problems. Decentralized development of a central schema is the GraphQL specialisation of a broader organisation-design problem (Conway's-Law avoidance, monorepo governance, distributed-ownership platforms). Non-GraphQL cousins:
    • Monorepo — same trade at the source-control altitude.
    • Microservices — same trade at the runtime altitude (many services + thin shared contract vs one service + thick shared codebase).
    • gRPC + protobuf with versioned service definitions — similar contract-decentralisation pattern at the RPC altitude.

Seen in

Last updated · 542 distilled / 1,571 read