gRPC vs REST
Protocol Buffers vs JSON serialization, streaming modes (unary/server/client/bidirectional), HTTP/2 multiplexing, and choosing the right API style.
Overview
Overview gRPC and REST are the two dominant API paradigms in modern distributed systems, and choosing between them has significant performance, developer experience, and operational implications. Understanding both deeply is expected at senior engineering levels at Google, Amazon, and Meta.
REST (Representational State Transfer) is an architectural style using HTTP/1.1 with JSON. It relies on standard HTTP verbs (GET, POST, PUT, DELETE, PATCH), stateless request-response patterns, and human-readable JSON payloads. REST's simplicity, browser compatibility, and universal tooling have made it the default for public-facing APIs.
gRPC is a high-performance RPC framework developed by Google, built on HTTP/2 and Protocol Buffers (protobuf). It uses a schema-first approach where services and messages are defined in .proto files, and code is generated for both client and server in dozens of languages. gRPC supports four communication patterns: unary (single request-response, like REST), server streaming (one request, multiple responses), client streaming (multiple requests, one response), and bidirectional streaming.
The performance difference is substantial in high-throughput scenarios. Protobuf serialization is 3-10x faster than JSON and produces payloads 2-5x smaller. HTTP/2 multiplexing eliminates head-of-line blocking and allows hundreds of concurrent requests over a single TCP connection. gRPC also supports flow control, header compression (HPACK), and built-in deadline propagation.
In production systems, gRPC is used for internal service-to-service communication (Google's internal Stubby protocol inspired gRPC), while REST or GraphQL is typically used for external APIs. Kubernetes uses gRPC for its API server communication with kubelets. Envoy proxy uses gRPC for its xDS configuration protocol.
Key concepts
- Protocol Buffers (protobuf)
- A language-neutral, platform-neutral binary serialization format developed by Google. Messages are defined in .proto schema files and compiled to code. Protobuf uses field numbers instead of field names in serialized format, making it compact and backward-compatible. A 1KB JSON payload often serializes to 200-400 bytes in protobuf.
- HTTP/2 Multiplexing
- HTTP/2 allows multiple logical streams over a single TCP connection using a framing layer. Each gRPC call is a stream. This eliminates the head-of-line blocking of HTTP/1.1 where a slow response blocks subsequent requests on the same connection. HTTP/2 also compresses headers with HPACK, reducing overhead for repeated headers like authentication tokens.
- gRPC Streaming Modes
- Unary: single request, single response (equivalent to REST). Server streaming: client sends one request, server returns a stream of responses (e.g., log tailing). Client streaming: client sends a stream of requests, server returns one response (e.g., file upload). Bidirectional streaming: both sides send streams concurrently (e.g., real-time collaboration).
- Deadlines and Cancellation
- gRPC has built-in deadline propagation. A client sets a deadline on a call, and the deadline is propagated to downstream services via gRPC metadata. If the deadline expires, all downstream calls are cancelled. This prevents cascading failures caused by hung upstream requests — a critical feature for production reliability.
- gRPC Transcoding
- A technique to expose gRPC services via HTTP/JSON, typically using an API gateway (like Envoy or Google Cloud Endpoints) that translates REST requests to gRPC calls. Allows internal gRPC services to be consumed by HTTP clients without changing the service implementation. Defined via google.api.http annotations in .proto files.
When to use it
- Designing high-throughput internal microservice APIs requiring low latency
- Building streaming APIs for real-time data feeds, logging pipelines, or chat systems
- Generating strongly-typed clients in multiple languages from a single contract
- Choosing between REST and gRPC for a new service in a polyglot microservices architecture
- Evaluating API gateway and service mesh configuration for gRPC traffic
Interview questions
- When would you choose gRPC over REST for a new microservice, and what operational considerations does that choice introduce?
- Explain how gRPC bidirectional streaming works and give a real-world use case where it is the right choice.
Sign up free to read the full topic
More Networking topics
Start free on Cariara · Coding problems · System design studio