gRPC - System Design Guide | Interview Forge

Overview

gRPC is a high-performance remote procedure call framework from Google. You define services and messages in Protocol Buffers (.proto files), generate strongly typed clients and servers in many languages, and call remote methods like local functions. It runs over HTTP/2, with compact binary messages and built-in streaming.

gRPC is the common choice for internal service-to-service communication where performance, strict contracts, and streaming matter. It is less suited to browsers (which need gRPC-Web through a proxy) and public APIs, where REST's universality usually wins.

A pre-agreed shorthand

REST with JSON is like writing full sentences each time. gRPC is like two colleagues who agreed on a numbered codebook in advance: messages are shorter and faster to read, but both sides must have the same codebook.

When to use it

Internal microservice communication with high call volume.
Polyglot systems that need generated, typed clients.
Streaming: server push, client upload, or bidirectional streams.
Low-latency, bandwidth-sensitive links (mobile to backend, IoT).

Where it shows up in interviews

Internal RPC layer

Recognize it when: many services calling each other at high QPS.

Design Uber's microservices
Design a payments platform's internal APIs

Streaming

Recognize it when: continuous updates between services or clients.

Design live location updates
Design a real-time chat backend

Where it is used in real software

Google

Google's internal RPC system, Stubby, inspired gRPC; nearly all Google services communicate this way.

Kubernetes and etcd

etcd exposes a gRPC API, and many cloud-native tools (Envoy xDS, containerd) use gRPC for control planes.

Netflix, Square, Dropbox

Use gRPC for internal service communication for performance and generated clients.

Key terms

Protocol Buffers: Language-neutral schema and binary serialization format.
Stub: Generated client code that makes a remote call look local.
Unary / streaming RPC: Single request-response, or server, client, or bidirectional streams.
Deadline: A per-call time limit propagated to downstream calls.
Field numbers: Numeric tags in .proto that make schema evolution safe.

How it works, step by step

1
Define the contract
Write service methods and messages in a .proto file.
2
Generate code
protoc generates client stubs and server interfaces for each language.
3
Implement the server
Fill in the generated interface methods.
4
Call from the client
client.getOrder({ id }) with a deadline; the stub serializes and sends over HTTP/2.
5
Evolve safely
Add new fields with new numbers; never reuse or renumber fields.

REST + JSON vs gRPC

Typical characteristics

Aspect	REST + JSON	gRPC
Payload	Text JSON	Binary protobuf (often 3-10x smaller)
Contract	Optional (OpenAPI)	Required (.proto)
Transport	HTTP/1.1 or HTTP/2	HTTP/2
Streaming	Limited (SSE, WebSockets)	Built in, bidirectional
Browser support	Native	Needs gRPC-Web proxy
Human readability	Easy to debug with curl	Needs tools (grpcurl)

NOWAspect: Payload | REST + JSON: Text JSON | gRPC: Binary protobuf (often 3-10x smaller)

A common architecture: REST or GraphQL at the edge for clients, gRPC between internal services.

Implementation

1syntax = "proto3";2package orders.v1;3 4service OrderService {5  rpc GetOrder(GetOrderRequest) returns (Order);6  rpc WatchOrderStatus(GetOrderRequest) returns (stream OrderStatus); // server streaming7}8 9message GetOrderRequest { string id = 1; }10 11message Order {12  string id = 1;13  string user_id = 2;14  int64 total_cents = 3;15  repeated LineItem items = 4;16  // field 5 was removed; reserve it so it is never reused17  reserved 5;18  string currency = 6;19}20 21message LineItem { string sku = 1; int32 quantity = 2; }22message OrderStatus { string status = 1; int64 updated_at = 2; }

Complexity and performance

SerializationMuch faster than JSON

Binary, schema-driven.

Connections1 HTTP/2 connection, many streams

Multiplexed.

Trade-offs

Performance vs accessibility

gRPC is faster and typed but harder to use from browsers, curl, and third parties.

Load balancing

Long-lived HTTP/2 connections defeat connection-level load balancers; use L7 (Envoy) or client-side balancing.

Variants and related techniques

gRPC-Web

A browser-compatible variant that goes through a proxy like Envoy.

Connect / Twirp

Simpler protobuf RPC protocols that also work over plain HTTP/1.1.

Common mistakes

No deadlines.
Fix: Always set deadlines; without them, a stuck downstream call hangs forever.
Reusing or renumbering fields.
Fix: Reserve removed field numbers and names.
L4 load balancing with gRPC.
Fix: All requests stick to one backend per connection; use L7 or client-side balancing.

Interview questions

Why is gRPC faster than REST with JSON?

Binary protobuf encoding is smaller and faster to parse than JSON text, HTTP/2 multiplexes many calls over one connection, and generated code avoids reflection-heavy serialization.

How does gRPC handle schema changes?

Fields are identified by numbers. Adding new optional fields is backward compatible; old clients ignore unknown fields. Never change a field's number or type; reserve removed ones.

Practice problems

Problem	Difficulty	What it trains
Write a .proto for a user service	Easy	Messages and services.
Design deadline propagation across 4 services	Medium	Timeouts.
Design internal RPC for a ride-hailing platform	Hard	Streaming and balancing.