gRPC
A high-performance RPC framework by Google using Protocol Buffers and HTTP/2. Much faster than REST for service-to-service communication.
What is gRPC?
In short
gRPC is an open-source remote procedure call framework from Google that lets one service call a function in another service over the network as if it were local. It serializes messages with Protocol Buffers and transports them over HTTP/2, which makes it faster and more compact than JSON-over-REST for service-to-service communication.
What gRPC actually is
gRPC stands for gRPC Remote Procedure Calls (the name is recursive, like GNU). It was built by Google in 2015 from an internal system called Stubby that already handled billions of calls per second across their data centers. The idea is simple: instead of building URLs, picking HTTP verbs, and parsing JSON, you just call a method like getUser(id) and gRPC handles moving the request and response across the wire.
You start by writing a .proto file that defines your service and its messages. A service lists the methods. A message lists the typed fields. From that single file, the gRPC compiler generates client and server code in over a dozen languages, so a Go server and a Java client agree on the exact shape of every message without anyone writing serialization code by hand.
This contract-first approach is the real selling point. The .proto file is the source of truth. Change a field and both sides regenerate, so a typo that would silently break a JSON API gets caught at compile time instead of in production.
How it works under the hood
Two technologies do the heavy lifting: Protocol Buffers and HTTP/2. Protocol Buffers (protobuf) is a binary serialization format. Instead of sending the field name user_id as text every time, it sends a small integer tag and the raw bytes of the value. A message that is 80 bytes as JSON might be 25 bytes as protobuf, and parsing it skips all the string scanning that JSON requires.
HTTP/2 is the transport. It multiplexes many calls over a single TCP connection, so hundreds of concurrent requests do not each need their own connection or wait in line behind each other. It also compresses headers and supports long-lived streams, which is what enables gRPC streaming.
gRPC supports four call types. Unary is the normal request-response. Server streaming sends one request and gets a stream of responses back, good for things like a feed of stock prices. Client streaming sends a stream of requests and gets one response, good for uploading chunks. Bidirectional streaming runs both directions at once over the same connection, which suits chat or live telemetry.
When to use it and the trade-offs
gRPC shines for internal service-to-service traffic inside your own infrastructure, especially in a microservices setup where one user request fans out to dozens of backend calls. The binary encoding, connection reuse, and code generation cut both latency and CPU compared to REST. Companies running large microservice fleets often see meaningful tail-latency improvements after switching internal calls to gRPC.
The main weakness is the browser. Browsers cannot speak raw gRPC because they do not expose the low-level HTTP/2 frame control gRPC needs, so a public-facing API for web apps usually still uses REST or GraphQL, or runs through a gRPC-Web proxy. gRPC is also harder to debug by hand. You cannot curl a binary protobuf endpoint and read the response, so you lean on tools like grpcurl or Postman's gRPC support.
Other trade-offs: the .proto contract adds a build step and a code-generation pipeline, and protobuf's strictness means you have to follow field-numbering and compatibility rules carefully when evolving schemas. For a small public API consumed by third parties, plain REST with JSON is often the more practical choice.
A concrete example
Picture an online store. The checkout service needs the current price for an item, the user's saved address, and a fraud score before it can place an order. Over REST that is three separate HTTP calls, each opening a connection, sending JSON headers, and parsing a JSON body.
With gRPC, the checkout service holds one persistent HTTP/2 connection to each backend and fires getPrice, getAddress, and getFraudScore as multiplexed calls in flight at the same time. Each message is a few dozen bytes of protobuf. The generated client code means the developer just writes pricingClient.getPrice(request) and gets back a typed Price object, no manual parsing.
If the catalog team later adds a currency field to the price message, they bump the field number, regenerate, and old clients that do not know about the field simply ignore it. Nothing breaks, and the upgrade is backward compatible by design.
Where it is used in production
Built gRPC from its internal Stubby system and runs it across nearly all internal service communication in its data centers.
Netflix
Uses gRPC for inter-service calls in its microservices backend to cut latency and serialization overhead versus REST.
Kubernetes
Components and the container runtime interface (CRI) between the kubelet and runtimes like containerd communicate over gRPC.
Cloudflare
Adopted gRPC for internal control-plane and service-to-service APIs where high throughput and a strict schema matter.
Frequently asked questions
- Is gRPC faster than REST?
- For service-to-service calls, usually yes. Protocol Buffers produce smaller payloads than JSON and parse faster, and HTTP/2 reuses a single connection for many concurrent requests. The gap is widest under heavy internal traffic; for a single occasional call the difference is small.
- Can I call a gRPC service from a web browser?
- Not directly. Browsers do not expose the HTTP/2 frame control gRPC needs. You use gRPC-Web with a proxy such as Envoy that translates between the browser and the real gRPC backend, or you expose a REST or GraphQL gateway in front.
- What is the difference between gRPC and Protocol Buffers?
- Protocol Buffers is just the data format used to serialize messages. gRPC is the full framework that defines services, generates client and server code, and moves those messages over HTTP/2. gRPC uses protobuf by default but they are separate things.
- What are the four types of gRPC calls?
- Unary (one request, one response), server streaming (one request, a stream of responses), client streaming (a stream of requests, one response), and bidirectional streaming (both sides stream at once over one connection).
- Should I use gRPC for a public API?
- Often not. For public APIs consumed by web frontends or third-party developers, REST with JSON is easier to debug, test with curl, and adopt. gRPC is the stronger choice for internal, high-volume communication inside your own infrastructure.
Learn gRPC hands-on
This page explains the idea. The full lesson lets you step through the ring as servers join and leave, read the implementation, and check yourself with a quiz. It is one of 760+ lessons in the System Design Masterclass, from your first API call to distributed consensus. Eleven Foundation lessons are free, no signup. Lifetime access is ₹499 in India or $7.99 worldwide, one payment, no subscription.
Related lessons
Lessons that touch on gRPC as part of a larger topic.
Apache Thrift
Facebook's cross-language RPC framework, the predecessor to gRPC with a wider transport layer
intermediate · api design protocols
Model Serving and Inference APIs: Turning a Model File Into a Service
How a packaged model becomes a live API that survives thousands of requests per second: online vs batch serving, the request path, REST vs gRPC, dynamic batching, autoscaling, tail latency, and safe rollout
ml-foundation · core
See also
Related glossary terms you might want to look up next.
REST API
An architectural style for building APIs using standard HTTP methods (GET, POST, PUT, DELETE). Resources are identified by URLs.
GraphQL
A query language for APIs where the client specifies exactly what data it needs. No over-fetching, no under-fetching. One endpoint to rule them all.
Microservices
An architecture where an application is split into small, independent services that communicate over the network. Each service owns its own data and can be deployed separately.
WebSocket
A protocol for full-duplex communication over a single TCP connection. Unlike HTTP, the server can push data to the client without being asked.
SSE
Server-Sent Events: a one-way channel where the server pushes updates to the client over HTTP. Simpler than WebSockets when you only need server-to-client streaming.
Rate Limiting
Controlling how many requests a client can make in a given time window. Protects your API from abuse and ensures fair usage.