gRPC — Google's RPC Framework
gRPC is a modern RPC framework built by Google on HTTP/2 and Protocol Buffers. It is typed, binary, streaming-capable, deadline-aware, and codegen-driven for a dozen languages. It is the de-facto standard for internal service-to-service communication at scale because it is dramatically faster and more expressive than JSON-over-HTTP, while still being a real protocol with real tooling.
How it works
gRPC is RPC built on three modern foundations:
1. HTTP/2 as the transport. HTTP/2 multiplexes many concurrent streams over a single TCP connection, supports binary framing, and has built-in flow control. This means a single client-server gRPC channel can carry thousands of concurrent RPCs without paying TCP handshake cost per call. The connection is long-lived and shared.
2. Protocol Buffers as the IDL and wire format. You define your service and messages in a .proto file:
service UserService {
rpc GetUser(GetUserRequest) returns (User);
rpc StreamUsers(ListUsersRequest) returns (stream User);
}
message GetUserRequest { int32 id = 1; }
message User { int32 id = 1; string name = 2; }The protoc compiler generates client stubs and server interfaces in your language. Protobuf is a binary format with a typed schema — fields are numbered, not named, on the wire, so adding a new field is backward-compatible by default. Messages are 3-10x smaller than JSON and serialize/deserialize much faster.
3. Generated, typed code in many languages. The same .proto file produces a Go client, a Java server, a Python client, a Rust client, and so on. Cross-language teams share one contract; the toolchain enforces it.
Together these give you an RPC framework that is fast, typed, polyglot, and streaming-native — properties no JSON-over-HTTP stack matches.
HTTP/2 is the secret sauce. REST over HTTP/1.1 has a fundamental limit: one request per TCP connection at a time (unless you pipeline, which browsers abandoned). To get concurrency you open 6 connections per host — each one pays TCP and TLS handshake cost, each one has its own congestion window, each one is a separate head-of-line blocking domain.
HTTP/2 multiplexes many streams over one connection. Every gRPC call is a stream with a stream ID; the client and server can have thousands of streams in flight on one TCP+TLS connection. This is much cheaper (one handshake, one congestion window, one TLS context) and much faster under load.
The downside is that HTTP/2 inherits TCP's head-of-line blocking: one lost TCP packet stalls every stream multiplexed over that connection. This is the motivation for HTTP/3 over QUIC (which fixes HOL blocking at the stream level). For internal service-to-service on a fast, low-loss datacenter network, HTTP/2 over TCP is excellent. For clients on flaky mobile networks, gRPC's head-of-line blocking is a real problem.
The other HTTP/2 win: binary framing. HTTP/1.1 is text (request line + headers + CRLF); HTTP/2 frames are length-prefixed binary, parsed faster and smaller on the wire. gRPC rides on these frames — a gRPC message is a length-prefixed protobuf inside an HTTP/2 DATA frame, with metadata (deadlines, auth, tracing) in HEADERS frames.
gRPC bakes in deadlines and cancellation propagation, which is the single feature that makes it production-grade.
Every gRPC call carries a deadline (an absolute timestamp by which the call must complete). If the deadline passes, the call is cancelled and the caller gets a DEADLINE_EXCEEDED error. Critically, the deadline propagates: when service A calls service B with 5 seconds remaining, A passes its remaining deadline to B, and B passes its remaining deadline to C. If A times out, B and C see the cancellation and abort their work too — they do not keep burning CPU on a request whose caller has given up.
This is a big deal. Without deadline propagation, a slow service causes cascading pile-ups: A waits for B, B waits for C, C takes 30s, A times out after 5s but B and C keep working uselessly. With propagation, the cancellation flows downstream the moment A gives up, freeing resources.
Other gRPC features that matter in production:
- Metadata: key-value headers (auth tokens, trace IDs, request IDs) that propagate through call chains. Distributed tracing libraries (OpenTelemetry) hook into these.
- Load balancing: gRPC clients can do client-side load balancing via DNS or xDS (Envoy's discovery service) — every call can be routed to a different backend without a proxy.
- Health checking: a standard
grpc.health.v1.Healthservice that load balancers probe. - Interceptors: client- and server-side middleware for auth, logging, metrics, retries.
- Keepalives: periodic pings to detect dead connections, important for long-lived channels behind load balancers.
Browsers cannot speak HTTP/2 trailers, which gRPC requires. gRPC-Web is a proxy (Envoy or a small Go server) that translates between browser HTTP/1.1 and backend gRPC. It works, but adds a hop and limits some streaming modes. For browser-driven apps, REST or GraphQL at the edge is often simpler; gRPC stays internal.
Beyond the protocol, gRPC is an ecosystem that solves problems RPC frameworks historically left to the user.
Health checking is a standardized service (grpc.health.v1.Health). Load balancers, k8s liveness probes, and service meshes probe it. A service that does not implement the health service is invisible to standard infrastructure.
Reflection lets clients discover the schema of a running server. Tools like grpcurl work like curl for gRPC: grpcurl -plaintext localhost:5000 list enumerates services, grpcurl ... UserService/GetUser invokes a method, with type-checked argument completion. Without reflection, you must have the .proto file locally.
Interceptors are middleware: client-side and server-side hooks for auth, logging, metrics, retries, tracing. Every gRPC server ships with interceptor chains; production setups compose 5-10 (auth, tracing, metrics, logging, rate limit, retry, deadline propagation).
Channel and connection management matters in production. A gRPC channel is a logical connection to a target; under the hood it manages a pool of HTTP/2 connections. Channels are expensive to create; reuse them. Client-side load balancing happens inside the channel: dns:///users-service:50051 makes the channel resolve DNS, pick a backend per RPC, and handle reconnection automatically. For more advanced routing (weighted, locality-aware), use xDS (Envoy's discovery service) which gRPC supports natively.
Observability tooling is mature: OpenTelemetry has first-class gRPC instrumentation; metrics, traces, and logs flow through interceptors automatically. The gRPC ecosystem's strong opinions on health, reflection, interceptors, and channels are why gRPC 'just works' in k8s and service meshes — the toolchain expects every service to expose the same surfaces, and it does.
Why does gRPC use HTTP/2 instead of HTTP/1.1?
Pick one answer.
Service A calls service B with a 5-second deadline. B takes 2s to call service C, then 3 more seconds of local work, totaling 5s — but A's deadline has passed. What does gRPC do, and why does it matter?
Pick one answer.
Which is a real disadvantage of gRPC compared to REST?
Pick one answer.
Engineering mental model
Mental model. Think of gRPC — Google's RPC Framework as a deliberate boundary in a system. The boundary exists because something becomes harder to manage when everything is done in one place: latency, scale, failure isolation, consistency, cost, or team ownership. The useful question is not “what does gRPC — Google's RPC Framework mean?” but “what pressure makes this boundary worth introducing, and what new failure mode does it create?”
Before choosing gRPC — Google's RPC Framework, name the workload, the critical user path, the dominant bottleneck, the failure you are trying to absorb, and the trade-off you are willing to accept. If you cannot name those five things, the design is probably premature.
curl -i https://api.example.com/v1/grpc
# Look for:
# - status code
# - latency
# - retryability
# - response sizeBack-of-the-envelope reasoning
Numerical lens: write down traffic, payload size, read/write ratio, peak multiplier and durability target before choosing a component. The numbers should justify the architecture.
Interactive thought experiment: gRPC — Google's RPC Framework
Change the variables below and predict what breaks first in gRPC — Google's RPC Framework. The production lab can later reuse these same inputs.
Change one variable at a time. Predict the failure mode first, then move the slider and see whether your mental model matches the simplified system response.
If you are stuck on gRPC — Google's RPC Framework, start by drawing the request path and marking every network hop, stateful component, queue, cache and failure boundary. Then estimate where the system will saturate.
You increase traffic by 10× in a system using gRPC — Google's RPC Framework. What should you inspect first?
Pick one answer.
Which statement is the safest engineering habit when using gRPC — Google's RPC Framework?
Pick one answer.
You have dashboards for traffic, latency, errors and saturation. You can change the architecture, but every change has operational cost.
Production scenario: your system uses gRPC — Google's RPC Framework, traffic suddenly spikes, and p99 latency doubles. What is your first move?
Interview drill
Answer this without notes: When would you choose gRPC — Google's RPC Framework, and when would you intentionally avoid it? Mention at least one bottleneck it addresses, one failure mode it introduces, and one alternative. Then quantify the workload you are designing for.
A useful engineering lens for gRPC - Google's RPC Framework: define the problem it solves, the simpler design that fails first, the constraint that forces you to introduce this concept, and the new failure modes the concept creates.
Numerical sanity check
Back-of-the-envelope reasoning beats fake precision. State your traffic, payload, concurrency and growth assumptions explicitly, then calculate enough to know whether the current architecture is orders of magnitude away from the target.
Do not optimize for a memorized definition. Reason from the workload and failure mode.
Imagine the simplest version of a system using gRPC - Google's RPC Framework. What breaks first as traffic grows by 10×, and what would you change before reaching 100×?
Pick one answer.
What you gain, what you pay
- +HTTP/2 multiplexing gives high concurrency on a single connection — no per-call handshake cost.
- +Protocol Buffers are 3-10x smaller than JSON and serialize/deserialize much faster.
- +Typed, code-generated stubs across many languages catch interface errors at compile time.
- +Four RPC types (unary + 3 streaming) cover nearly every service-to-service pattern.
- +Deadline and cancellation propagation prevents cascade failures.
- +Metadata, interceptors, and standard health checks make observability and ops tractable.
- −Requires IDL toolchain and codegen — operational complexity.
- −Browsers cannot speak gRPC natively — requires gRPC-Web proxy, limiting browser use.
- −Not human-readable on the wire (binary protobuf) — harder to debug without tooling.
- −Schema evolution requires IDL discipline (field numbers, reserved fields).
- −HTTP/2 inherits TCP head-of-line blocking across multiplexed streams (HTTP/3 fixes this).
How this breaks in production
- Long-lived gRPC connections killed silently by load balancers or NATs with short idle timeouts — mitigated by keepalives.
- Deadlines not set (or set to 0 = infinite) — a slow service takes down every caller.
- Cancellation not propagated because interceptors do not pass context — wasted work downstream.
- Single shared channel becomes a bottleneck when saturated — use channel pooling or per-target channels.
- HTTP/2 head-of-line blocking across multiplexed streams on lossy links — fixed by HTTP/3 over QUIC.
- Proto schema breakage deployed without coordination — old clients crash on new fields.
Don't fall into these traps
- •Forgetting to set deadlines — the default is no deadline, which is almost never what you want.
- •Not propagating trace IDs through metadata — distributed traces become useless.
- •Using a single TCP channel for everything — saturates under high load.
- •Treating gRPC like REST (one call per request) instead of streaming where streaming fits.
- •Breaking proto changes (renumbering fields, reusing field numbers) — corrupts old clients.
- •Not enabling keepalives — dead connections accumulate behind load balancers.
Real systems using this
How real systems implement this
- Google internal services — Originally built gRPC (as Stubby) for internal use. Billions of RPCs per second across tens of thousands of services, all deadline-propagated and trace-instrumented.
- Netflix studio and streaming backend — Migrated many internal service-to-service calls from HTTP/JSON to gRPC for the typed contracts and streaming support. Reduced latency and caught interface drift at compile time.
- Kubernetes control plane — kube-apiserver, kubelet, kube-proxy, and the scheduler all communicate via gRPC. Watch endpoints are server-streaming RPCs.
Practice saying it out loud
- Q1gRPC vs REST vs GraphQL — when would you choose each?
- Q2Explain gRPC's four RPC types and give a realistic use case for each.
- Q3How does deadline propagation work in gRPC, and why does it matter for cascade failures?
- Q4Why does gRPC use HTTP/2? What does it gain over HTTP/1.1?
- Q5Your team has a browser-based client and an internal service. How do you architect the API tiers?
Further reading & references
Core explanations are original NO CAP material. External references are provided for deeper study and standards.
What next?
Mark as understood once the mental model clicks.
Next recommended
REST — Representational State Transfer