REST vs gRPC vs GraphQL

People compare these three as if they were rival wire formats. They are not. REST is a set of conventions that lets the web's infrastructure — caches, CDNs, proxies, browsers — understand your API. gRPC is a contract-first RPC system that makes service-to-service calls typed, compact and deadline-aware. GraphQL is a query layer that moves the shape of the response to the client, so many screens can share one backend without a new endpoint each. Most mature systems run two of them at once. The question that decides it is: who is on the other end of the wire, and who controls their release cycle? If it is a stranger's code or a browser, you want HTTP semantics. If it is your own service deployed by your own CI, you want a compiled contract. If it is a fleet of your own clients whose screens change weekly, you want the client to choose its fields.

Go deeper:

• Deadlines, retry and hedging config, and why L4 balancing pins gRPC connections are covered in gRPC.

The Verdict#

Default: REST (JSON over HTTP) at the public edge, gRPC between internal services, and GraphQL only when many first-party client screens aggregate data from many backends.

🎯 Staff Move: "I'll keep the public API as versioned REST because partners integrate with curl and our CDN caches the catalog reads. Inside, services talk gRPC with deadlines. I'd only add GraphQL if we end up with three client teams each building their own aggregation endpoints."

When the non-default wins:

• gRPC at the public edge wins when your "public" clients are a small set of sophisticated integrators (trading firms, IoT fleets you ship firmware to) who value streaming and compact payloads over curl-ability.
• REST internally wins when the org has fewer than ~10 services, low RPS, and no platform team to own a mesh. JSON over HTTP with a shared client library is cheaper to run than a gRPC stack nobody owns.
• GraphQL for a single web app rarely wins. One client and one backend team gain little that a well-designed REST endpoint does not already give them.

At a Glance#

The throughput and serialization figures are orders of magnitude for small (under ~1KB) messages on a modern core; they move a lot with payload size and framework. The ratios hold better than the absolutes.

How They Actually Differ#

1. Who Owns the Shape of the Response#

This is the deepest difference, and it is organizational, not technical.

REST and gRPC put the server team on the critical path of every UI change. That is fine when the clients are few and stable, or when the consumer is another service. It becomes a bottleneck when 3 client teams ship weekly and each needs a slightly different view of the same entities. The usual REST workaround is a backend-for-frontend (BFF) per client — which works, and is often the right answer for 2 clients. GraphQL is what you reach for when the BFF count heads toward 5+ and they are all reimplementing the same joins.

🎯 Staff Insight: GraphQL does not remove the aggregation work. It moves it into resolvers owned by a platform team. Adopt it when you are ready to staff that team.

2. Caching: The Web's Free Infrastructure#

REST inherits 30 years of HTTP caching. A GET /products/123 with Cache-Control: max-age=60 and an ETag is cacheable by the browser, the CDN and any reverse proxy, with conditional revalidation (304 Not Modified) costing a few hundred bytes. For a read-heavy public API, a CDN hit ratio of 90%+ means the origin sees one request in ten.

gRPC has no HTTP-level caching story: every call is a POST-like stream over HTTP/2. Caching lives in the service (a local LRU or Redis), which is fine because internal callers are not geographically spread.

GraphQL is the hard case. Queries are usually POSTed to /graphql, so CDNs see one URL with varying bodies. The fixes are persisted queries (the client sends a hash, the server maps it to a known query, and the request can become a cacheable GET) and normalized client caches keyed by type and ID. Both work; both are extra machinery someone must own.

The diagram is the shape most large systems converge on: HTTP semantics where the internet is involved, compiled contracts where only your services are.

3. The Contract and How It Evolves#

GraphQL's underrated advantage is field-level usage telemetry: you can see that user.legacyAvatarUrl was requested 4 times last week and by which client version. Protobuf's advantage is that the compiler catches drift before deploy. REST's JSON has neither by default; teams bolt on OpenAPI and contract tests.

4. Connections, Load Balancing and Streaming#

gRPC runs over HTTP/2, multiplexing thousands of concurrent calls on one TCP connection. That saves handshakes (a TLS handshake costs 1–2 round trips; on a 50ms cross-region link that is 50–100ms per new connection) but breaks L4 load balancing: an L4 balancer spreads connections, and if a client holds one connection for hours, every request goes to one backend. You need per-request (L7) balancing in a proxy or sidecar, client-side balancing with a resolver, or a maximum connection age (commonly 5–30 minutes) that forces reconnection.

Streaming is native in gRPC: a server stream is the natural shape for "send me price updates" between services. REST needs SSE or WebSocket for that. GraphQL subscriptions usually ride WebSocket and bring their own operational concerns (sticky connections, fan-out, reconnect storms) — see Live Updates.

5. Where the Cost Hides#

REST cost is visible: one request, one handler, one bill. gRPC cost is visible too. GraphQL cost is a function of the query, and a client can write a query that fans out to 10,000 backend calls. Without per-request batching (a loader that collapses getItems(id) calls into batchGetItems(ids) within one tick) every list field becomes an N+1. Without query cost analysis — depth limits (commonly 7–10), a complexity budget per query, and timeouts — a single malicious or careless query can take down shared backends. Public GraphQL APIs typically rate-limit by computed query cost, not by request count.

Where Each One Breaks#

The production surprise for each:

• REST: the bottleneck is usually not the API, it is the round trips. A 6-call screen on mobile is a latency bug no server optimization fixes.
• gRPC: teams adopt it for speed and get burned by load balancing. The first incident is almost always "one pod is hot".
• GraphQL: dashboards lie. Request count is flat while backend load triples because a client shipped a heavier query.

Incident Sketch: The Hot Pod After a Deploy#

t=0        Deploy rolls the pricing service from 12 to 12 new pods, one at a time
t=+4min    Callers' HTTP/2 connections reconnected to the first 3 pods that came up
t=+5min    Pod 1: 92% CPU, p99 340ms. Pods 4–12: 8% CPU
t=+6min    Upstream deadlines (100ms) start firing; checkout error rate 3%
t=+9min    On-call scales to 20 pods. Nothing improves: new pods get no connections
t=+14min   Rolling restart of callers spreads connections; error rate back to 0.1%

Detection: per-pod CPU skew (max/median > 3), grpc_server_handled_total by pod, client-side DEADLINE_EXCEEDED rate. Root cause: L4 balancing of long-lived connections. Prevention: client-side round-robin over resolved endpoints or an L7 sidecar, plus a max connection age of ~10 minutes so connections rebalance after every deploy. Owner: the platform team that owns the mesh defaults — not each service team.

Incident Sketch: The Query That Shipped in a Mobile Release#

t=0        App release adds 'recent orders with items and reviews' to the home screen
t=+2h      Adoption reaches 20% of DAU. GraphQL request rate: flat
t=+3h      Review service p99 from 40ms to 900ms; it now gets 25 calls per home-screen load
t=+3h10m   Review service sheds load; home screen renders with null review fields, HTTP 200
t=+4h      A product manager notices empty review stars. No alert fired

Detection that would have caught it: resolver-level call counts per operation name, backend RPS split by calling GraphQL operation, and an alert on the per-field errors rate rather than HTTP 5xx. Prevention: a loader batching per request, a query cost budget enforced in CI against persisted queries, and a load test for every new persisted query above a cost threshold.

Cost and Operations#

Rough numbers for a fleet doing 200K internal RPS: moving from JSON/HTTP to protobuf/gRPC commonly saves 30–60% of serialization CPU and 50–70% of bytes on the wire for structured payloads. That is real money at 200K RPS and irrelevant at 200 RPS. At low volume, pick for developer experience, not efficiency.

Assumptions: cloud compute list prices, small structured payloads, people cost dominating until roughly 50K RPS.

🧭 Principal Insight: The cost of GraphQL is not the gateway's CPU. It is the permanent team that owns the schema and the governance process 30 product teams must follow. Price that headcount before you adopt it.

Switching Later#

The one-way doors:

1. A public API contract. Whatever partners integrate against, you support for years. Start with REST and additive-only changes.
2. GraphQL in shipped mobile apps. Old app versions keep sending old queries. Persisted queries help: you know exactly which queries exist and can keep them working.
3. Protobuf field numbers. Reusing a number corrupts data for any old binary still running. Mark removed fields reserved forever.

The safe migration pattern for internal gRPC adoption is the one large companies report: freeze new features on the legacy RPC stack, define the shared interface layer first (auth, discovery, metrics, deadlines), then migrate clients incrementally. The migration takes longer than building the new framework.

Adopting GraphQL without a big bang:

1. Stand up the gateway in front of existing REST and gRPC services; resolvers call them, nothing below changes.
2. Move one high-traffic screen; measure round trips and payload bytes before and after.
3. Make persisted queries mandatory for first-party apps from day one — retrofitting them later means supporting arbitrary queries from every old app version.
4. Assign type ownership before the second team contributes.

How Real Companies Chose#

Facebook — GraphQL for Mobile News Feed#

Facebook started GraphQL in 2012 while rebuilding its native iOS and Android apps. News Feed had only been delivered as HTML, and the REST and FQL approaches made developers write a lot of code on the server to prepare data and on the client to parse it, with a mismatch between what the app needed and what the queries returned. By 2015 GraphQL served millions of requests per second from nearly 1,000 shipped app versions (Facebook Engineering).

Staff insight: GraphQL was born for many app versions with fast-changing screens. "Nearly 1,000 shipped versions" is the condition under which it wins — not a single web app talking to a single backend.

GitHub — Adding a GraphQL API Next to REST#

GitHub launched its GraphQL API because its REST API generated over 60% of the requests to its database tier, responses carried too much data and still missed what consumers needed, and integrators often needed two or three calls to assemble one view. GraphQL also gave them a typed schema for documentation, scopes and client generation. The REST API stayed (GitHub Blog).

Staff insight: Even the company that went all-in on GraphQL kept REST for its public integrators. You add GraphQL for the clients it helps; you do not rip out the API your partners depend on.

Dropbox — Migrating Internal RPC to gRPC#

Dropbox replaced a legacy HTTP/1.1 RPC framework with protobuf encoding by Courier, a gRPC-based layer adding Dropbox's auth, service discovery, stats, logging and tracing, across hundreds of services and millions of requests per second. They chose gRPC because it kept their existing protobuf investment and added HTTP/2 multiplexing and bidirectional streaming. The biggest reliability win: requiring deadlines in service definitions removed whole classes of problems. They also note the migration took far longer than development (Dropbox Tech).

Staff insight: The value was not the binary format. It was a single framework where deadlines, observability and auth are mandatory. Say that, and you sound like someone who has run the migration.

Follow-Ups to Expect#

What to Say in the Interview#

"The deciding question is who sits on the other end of the wire. Partners and browsers get REST, because they need HTTP caching and curl-level tooling. Our own services get gRPC with a deadline on every call."

"I'd only introduce GraphQL if we have several client teams building their own aggregation endpoints — and then I'd staff a platform team to own the schema, batching and query cost limits."

"With gRPC I'd plan load balancing up front: client-side or L7 balancing plus a maximum connection age, because an L4 balancer will pin each long-lived connection to one pod."

"Protobuf saves roughly 2 to 5 times the CPU and bytes of JSON, which matters at a few hundred thousand requests per second and not at all at a few hundred."

Related Guides#

• API Contracts — idempotency, pagination, versioning and error contracts for all three styles
• Latency and Protocols — HTTP/2, HTTP/3 and the gRPC load-balancing problem in depth
• Envoy, Kong and NGINX — the proxies that do L7 balancing and protocol translation
• Design an Edge Gateway — where the REST/GraphQL edge lives
• Design Live Updates — streaming and subscriptions at scale
• Push vs Poll — choosing between streams, SSE and polling
• Design a News Feed — the classic aggregation-heavy client screen