Skip to content

PATTERN Cited by 2 sources

GraphQL as unified API platform

When to use

You have many backend services whose data is consumed by many client applications (web, mobile, internal tools, partner APIs), and you want:

  • One schema across clients, so the API contract is a single source of truth.
  • Rapid API evolution — days, not months — without version-bumping clients.
  • A measurement surface for usage, deprecation, and performance.

The pattern

Deploy a GraphQL gateway layer between clients and backend services. The gateway owns the schema; backend services implement resolvers. Client queries specify exactly what fields they want; the gateway federates across services.

      Client queries (web, iOS, Android, partners)
                       │
                       ▼
       ┌─────────────────────────────┐
       │ GraphQL gateway (one schema) │
       └────────┬──────────┬──────────┘
                ▼          ▼
         user-service   timeline-service  …  (resolver-per-service)

Canonical examples (from the Dec 2022 roundup)

Twitter (pre-layoffs)

Per @jbell (summarized in the High Scalability Dec-2022 roundup):

"Over 5 years, we've migrated almost every api used by the Twitter app into a unified graphql interface. Getting api changes into production used to be measured in weeks, now it's measured in hours. For the last 2 years, EVERY SINGLE new Twitter feature was delivered on this api platform. Twitter blue, spaces, tweet edit, birdwatch, and many many many others."

Scale disclosed: 1.5 billion GraphQL fields per second across 3,000 different data types; in CY2022 1000+ changes by 300+ developers. The GraphQL system also serves Twitter's entire third-party developer API.

Netflix

1 billion daily GraphQL requests (2022 InfoQ datapoint).

Zalando (added 2026-04-24 from 2021 retrospective)

Zalando's Unified Backend-For-Frontends (UBFF) GraphQL is the single-service implementation of this pattern — 12+ domains in one monorepo, one schema, one deployment artifact, serving >80% of Web and >50% of App use cases across 200+ consuming developers in 25-30 feature teams. Went to production end of 2018; 150+ contributors as of Feb 2021. Runs on Zalando's in-house open-source graphql-jit JIT-compiled GraphQL executor. Source: .

Key Zalando-specific variant: strict "No Business Logic" principle in the GraphQL layer; all domain/platform logic moves to a downstream presentation layer. And: per- platform deployment bulkhead (separate instances of the same service for Web vs mobile Apps) as the explicit Bulkhead fault-isolation pattern.

Implementation topology split

The pattern has three runtime topologies. All are legitimate instances of GraphQL-as-unified-API-platform:

The schema commitment (one graph) is the same across all three; the topology choice trades tooling/deploy unity (UBFF) against per-domain autonomy (Federation), with the multi-tenant runtime sitting between the two — collapsing Federation's per-team server cost while sacrificing Federation's per-team deploy independence. The underlying discipline is concepts/unified-graph-principled-graphql; the problem space is concepts/decentralized-development-of-central-schema.

Why it's powerful

  • Client-driven field selection eliminates over-fetching — mobile clients get exactly what they need, reducing egress and render time.
  • Single evolution timeline: shipping a new feature means adding fields + a resolver, not coordinating version bumps across N client binaries.
  • Schema-level deprecation tracking: you can measure exactly which field each client is using and deprecate dead fields with confidence.
  • Federation (Apollo Federation, Netflix's DGS, etc.) lets multiple services own their slice of the schema without a single-team bottleneck.

Trade-offs

  • Resolvers can fan out expensively. A naive GraphQL query can trigger many backend calls; protect with DataLoader-style batching + depth/complexity limits.
  • Caching is harder than REST — HTTP caching doesn't map cleanly because every query is a unique URL + body. Use a GraphQL-aware cache (Apollo's, or a persisted-query layer).
  • Gateway is a single-point-of-failure — must be designed for SLO equal to the worst-case client's uptime budget.
  • Sharp edges at scale: Rick Houlihan's critique, paraphrased elsewhere in the same roundup, is that "GraphQL
  • single-table NoSQL is a trap" — the flexibility of GraphQL makes it easy to generate access patterns that a NoSQL data model wasn't tuned for. Cite the specific quote, not GraphQL wholesale.

Cousin pattern: protocol-unified gateway

Tinder's TAG is the protocol-unified sibling of GraphQL's schema-unified approach: TAG unifies HTTP/gRPC/auth/rate-limit at one gateway layer, while leaving REST/gRPC payloads alone. Twitter's GraphQL platform unifies the schema on top.

Seen in

Last updated · 542 distilled / 1,571 read