gRPC Explained: Protobuf, HTTP/2, Streaming and Microservices

gRPC is Google's open-source RPC framework that uses HTTP/2 for transport and Protocol Buffers for serialization. It enables typed, bidirectional communication between services at a fraction of the latency of JSON over REST. In system design, gRPC is the go-to choice for internal microservice communication where performance matters — it is 5-10x faster than REST/JSON for serialization and supports streaming natively.

Why This Matters

In microservice architectures with dozens of services communicating at high frequency, the overhead of JSON serialization and HTTP/1.1 connection management becomes a bottleneck. gRPC eliminates both problems: Protocol Buffers serialize data to compact binary (10x smaller than JSON), and HTTP/2 multiplexes many requests over a single TCP connection. When Netflix or Google routes millions of inter-service calls per second, those savings compound into real infrastructure cost reductions.

The Building Blocks

• Protocol Buffers: Binary serialization format that defines message schemas in .proto files. The compiler generates typed client and server code in any language. Messages are 3-10x smaller than JSON and parse 5-10x faster.
• HTTP/2 Transport: Multiplexed connections allow hundreds of concurrent RPCs over a single TCP connection. Header compression (HPACK) reduces overhead. Server push enables efficient streaming patterns.
• Service Definition: The .proto file is the single source of truth — it defines service methods, request/response types, and streaming modes. Both client and server generate code from the same .proto, eliminating contract drift.
• Streaming Modes: Four patterns: unary (request-response), server-streaming (one request, many responses), client-streaming (many requests, one response), and bidirectional streaming (both sides send freely).
• Interceptors: Middleware chain for cross-cutting concerns — authentication, logging, metrics, retry logic. Both client-side and server-side interceptors wrap every RPC call without touching business logic.
• Deadlines and Cancellation: Every RPC carries a deadline that propagates across the call chain. If service A calls B calls C with a 500ms deadline, C knows how much time remains and can bail early.

Under the Hood

When a gRPC client calls a method, the request is serialized to compact binary using Protocol Buffers, wrapped in an HTTP/2 frame with metadata (deadlines, auth tokens, tracing headers), and sent over a multiplexed connection. The server deserializes the binary payload into a typed object, executes the handler, and returns the response the same way.

The key performance advantage is the binary encoding. A JSON payload like user_id=12345, name=Alice becomes a 12-byte Protobuf message instead of a 40-byte JSON string. Multiply that difference by millions of RPCs per second and you save gigabytes of bandwidth and CPU cycles spent on parsing. HTTP/2 multiplexing means these millions of RPCs share a handful of TCP connections instead of opening a new one per request.

For streaming, gRPC maintains an open HTTP/2 stream where either side can send messages at any time. This is ideal for real-time feeds, log tailing, or chat — the connection stays open and messages flow as they are produced.

How Companies Actually Do This

Google uses gRPC for virtually all internal service communication. Every Google product — Search, Gmail, YouTube — relies on gRPC for backend service calls. The framework was designed for Google's scale of billions of RPCs per second.

Netflix adopted gRPC for inter-service communication in their Java microservices. The typed contracts reduced integration bugs, and the binary encoding cut network bandwidth by 60% compared to their previous JSON-based approach.

Uber migrated from Apache Thrift to gRPC for their 4,000+ microservices. The native deadline propagation solved their cascading timeout problem, where slow downstream services would consume resources in upstream services.

Common Pitfalls

1. Using gRPC for browser-facing APIs without a gRPC-Web proxy — browsers cannot make raw HTTP/2 requests with trailers
2. Ignoring deadline propagation — without explicit deadline forwarding, a 200ms client timeout can trigger a 30-second downstream call that wastes resources
3. Breaking backward compatibility in Protobuf schemas by reusing field numbers or changing field types instead of adding new fields

Interview Questions Worth Practicing

1. When would you choose gRPC over REST for microservice communication, and when would REST be better?
2. How does gRPC achieve lower latency and smaller payloads than JSON-based REST?
3. Explain how deadline propagation works in gRPC and why it matters for cascading failures.

The Tradeoffs

• Performance vs Debuggability: Binary Protobuf is 5-10x faster than JSON but you cannot read payloads with curl or browser dev tools. Debugging requires Protobuf-aware tooling like grpcurl or Kreya.
• Strong Typing vs Flexibility: Schema enforcement catches integration errors at compile time, but requires code generation, build tooling, and schema registries. REST with JSON is more forgiving for rapid iteration.
• HTTP/2 Requirement vs Compatibility: Multiplexing and header compression reduce latency significantly, but HTTP/2 complicates load balancing (L7 required) and some older proxies do not support it.

How to Explain This in an Interview

Here is how I would explain gRPC in a system design interview:

I start by explaining when I would pick gRPC over REST. For internal microservice communication where latency matters and both sides are controlled by my team, gRPC wins: binary serialization via Protobuf makes payloads 5-10x smaller, and HTTP/2 multiplexing avoids the connection overhead of REST. The .proto file acts as a typed contract — schema mismatches are caught at compile time rather than at 3 AM in production. For streaming use cases like live feeds or bidirectional chat, gRPC's native streaming is a natural fit. But for public-facing APIs where any HTTP client needs to connect, REST with JSON is simpler because every tool speaks JSON natively. I would also mention deadline propagation — gRPC automatically forwards timeout budgets across service calls, which prevents cascading failures.

Related Topics

• REST vs GraphQL
• API Design
• WebSockets
• API Gateway

Original DosiBridge notes for gRPC Explained: Protobuf, HTTP/2, Streaming and Microservices

This section is written specifically for this page, not copied from a general system-design checklist. The useful way to study gRPC Explained: Protobuf, HTTP/2, Streaming and Microservices is to connect the concept to a production service where growth exposes the first weak assumption in the original design. That framing changes the design discussion from definitions to operating choices.

What makes this topic distinct

• Contract Evolution: For gRPC Explained: Protobuf, HTTP/2, Streaming and Microservices, decide the contract evolution before choosing tools; otherwise the design looks clean but fails when grpc changes.
• Idempotency: For gRPC Explained: Protobuf, HTTP/2, Streaming and Microservices, decide the idempotency before choosing tools; otherwise the design looks clean but fails when grpc changes.
• Pagination: For gRPC Explained: Protobuf, HTTP/2, Streaming and Microservices, decide the pagination before choosing tools; otherwise the design looks clean but fails when grpc changes.
• Error Shape: For gRPC Explained: Protobuf, HTTP/2, Streaming and Microservices, decide the error shape before choosing tools; otherwise the design looks clean but fails when grpc changes.
• Consumer Compatibility: For gRPC Explained: Protobuf, HTTP/2, Streaming and Microservices, decide the consumer compatibility before choosing tools; otherwise the design looks clean but fails when grpc changes.

Production review question

If a team adopts gRPC Explained: Protobuf, HTTP/2, Streaming and Microservices, what observable signal proves it helped instead of only making the architecture diagram more fashionable?

Practical metric to track

Track grpc health as a named dashboard or review item: combine one user-facing metric, one saturation metric, and one correctness metric. For gRPC Explained: Protobuf, HTTP/2, Streaming and Microservices, this keeps the discussion grounded in behavior that can be measured after deployment instead of generic advice that sounds good in an interview but never gets verified.