gRPC

Pradeep P
3 days ago
3 min read

Series: Modern System Design · Layer 2 — Communication

Layer 2 · Post 2 of 10

← Previous: REST APIs → Next: Synchronous vs Asynchronous Communication

Layer 2 — Communication · Post 17 of 88

gRPC is a high-performance RPC framework that uses HTTP/2 and protobufs. Services call each other as if they were local functions.

What you'll learn

How gRPC differs from REST: contracts, payloads, and HTTP/2
Unary vs streaming RPCs
When to use gRPC inside the datacenter — and when not to expose it to browsers

The idea in one minute

gRPC is remote procedure call done as a product: you write a .proto file that says this service has this method, these arguments, this return type. Code generators build clients and servers in many languages.

On the wire it uses HTTP/2 and Protocol Buffers (binary, schema'd messages) instead of JSON text.

To the programmer it looks like order = stub.GetOrder(id). To the network it is a multiplexed binary stream. That is faster and stricter than most REST.

Why it matters

REST is great at the edge. Inside a mesh of 50 microservices, JSON and HTTP/1.1 start to cost:

Payload size (every field name, every time)
No native streaming (you fake it with chunked encoding or websockets)
Weak contracts (the JSON can drift from what the other team expected)

gRPC makes the contract the source of truth and makes many small calls cheaper. Kubernetes, Envoy, and most service mesh stories assume protobufs somewhere.

How it works

The contract

You define a service with RPCs such as GetNote and StreamUpdates. Change the proto, regenerate, both sides compile against the same types. Backward compatibility is a proto skill (don't reuse field numbers).

Four call types

Unary: one request, one response. Like a function.
Server streaming: one request, many responses (log tail, token stream).
Client streaming: many requests, one response (upload).
Bidirectional: both streams open (low-latency chat between services).

REST can approximate some of this. gRPC makes it first-class.

HTTP/2

Many requests share one connection. Headers are compressed. The server can push messages without a new handshake each time. That helps tail latency between services in the same region.

Errors

gRPC has its own status codes (NOT_FOUND, UNAVAILABLE, DEADLINE_EXCEEDED) mapped onto HTTP/2. Deadlines (timeouts) are part of the API, not an afterthought — you pass a deadline with the call. Layer 3 will lean on that.

A simple example

Checkout calls Inventory and Payments.

With REST: two JSON POSTs, two connection setups if you are unlucky, two slightly different error shapes.

With gRPC: one HTTP/2 connection to each service (often pooled), protobuf ReserveStock and Charge, generated stubs in Go and Java that agree on field names. A 5 ms internal call stays closer to 5 ms.

You still put REST (or GraphQL) at the public edge. The mobile app does not speak gRPC easily in a browser. grpc-web exists; many teams keep REST outside and gRPC inside.

Common mistakes

Exposing gRPC on the public internet without a plan. Firewalls, browsers, and some load balancers are still happier with HTTP/1.1 JSON. Use a gateway that translates.

Treating proto as optional documentation. If servers hand-roll JSON and clients ignore the .proto, you bought a compiler for nothing.

Huge messages. Protobufs are not a license to send 50 MB blobs on the RPC. That's a file/object store.

Forgetting load balancing. HTTP/2 connection reuse can pin you to one backend. You need L7 or client-side balancing that understands gRPC (Envoy, lookaside LB). This surprises people who came from REST + round-robin.

How this shows up in real systems

Google, many Kubernetes controllers, Envoy xDS: gRPC internally.
ML / LLM serving: gRPC or similar binary RPCs between gateway and GPU boxes (Layer 6).
Connect / Twirp / Cap'n Proto: cousins of the same idea.

Interview line: REST at the edge, gRPC between services, if latency and strict schemas matter.

Recap

gRPC is RPC + protobufs + HTTP/2: typed, compact, stream-capable.
Best inside the datacenter. Keep a friendlier HTTP API for humans and browsers.
Deadlines and generated contracts are features, not extras.

REST and gRPC are both usually synchronous: you wait. The next post is when waiting is the wrong idea.

Series: Modern System Design · Layer 2 — Communication

Layer 2 · Post 2 of 10

← Previous: REST APIs → Next: Synchronous vs Asynchronous Communication