Why architecture matters here
gRPC architecture matters because rolling your own RPC is a mistake most teams make once. Framing, schema evolution, streaming, load balancing, retries with deadline — each is subtly hard. gRPC packages a battle-tested implementation of all of them behind a clean API.
Cost matters because Protobuf is 5-10x more efficient on the wire than JSON. At high volumes this compounds into meaningful bandwidth savings. HTTP/2 multiplexing collapses N TCP connections into 1.
Reliability comes from features baked into the framework. Deadlines propagate through the call chain automatically; interceptors give you consistent auth and metrics; retries with backoff are configured, not coded. Each of these is a class of bug you avoid.
The architecture: every piece explained
Walk the diagram top to bottom.
Client Stub. Generated from your .proto file. Language-native calls that hide protobuf serialization and HTTP/2 framing.
HTTP/2 Multiplex. Multiple concurrent streams over one TCP connection. No head-of-line blocking within streams (only within the TCP stream itself). Binary framing, HPACK header compression.
Server Stub. Generated dispatcher. Deserializes protobuf, invokes your handler, serializes the response.
Protobuf Serialization. Compact binary encoding with a schema. Field numbers rather than names save bytes. Backwards/forwards compatible when you follow the rules.
Interceptors. Middleware. Auth (check JWT), metrics (record latency), retry policy, logging. Client and server sides both support interceptors.
Unary RPC. Classic request/response. Most APIs.
Server Streaming. Client sends one request; server streams many responses. Good for feed-like APIs, LLM token streaming.
Bidi Streaming. Both sides stream independently. Chat, real-time collaboration, telemetry.
Load Balancing. Client-side (round-robin over resolved endpoints), xDS (service mesh integration), or through an L7 proxy. Client-side skips a hop.
Deadline Propagation. The context carries a deadline. Every downstream RPC inherits or shortens. Prevents runaway calls.
gRPC-Web + grpc-gateway. Browsers can't speak raw gRPC; gRPC-Web is a browser-friendly variant. grpc-gateway generates a REST proxy so REST clients can consume gRPC services.
End-to-end call flow
Trace a call. Client generates a stub from user.proto. It calls stub.GetUser(GetUserRequest{id: 42}, deadline=1s).
Interceptor chain: auth adds JWT to metadata; retry policy is configured with 2 retries and 100ms backoff.
Serializer encodes to protobuf: field 1 (id) = 42 in varint form. Total wire ~5 bytes plus framing.
HTTP/2 stream is opened. Request travels over the existing connection to the server. Server dispatches via generated stub to GetUser handler.
Handler reads from DB (with the deadline propagated), builds a User protobuf response. Serialized to wire.
Response streams back. Client stub deserializes into language-native User object. Metrics interceptor logs latency. Deadline was 1s; total elapsed 12ms.
For a streaming RPC, LLM tokens: server yields responses as they arrive; client iterates over the stream. HTTP/2 handles interleaving with other concurrent streams on the same connection.