Key Question

What makes gRPC different from traditional RPC?

Deep Dive

gRPC is Google’s open-source RPC framework built on HTTP/2 and Protocol Buffers. It’s not just “RPC with Protobuf” — the streaming model fundamentally changes what’s possible.

Four Service Types

gRPC defines four kinds of RPC calls, each useful for different patterns.

1. Unary RPC — Standard request-response. Client sends one message, server replies with one.

  Client ─── Request ──►  Server
        ◄── Response ──

2. Server-Streaming — Client sends one request; server pushes a stream of responses.

  Client ─── Request ──►  Server
        ◄── Response 1 ──
        ◄── Response 2 ──
        ◄── Response 3 ──  (server closes stream)

Useful for: real-time feed, large result sets, progress updates.

3. Client-Streaming — Client pushes a stream of messages; server replies once.

  Client ─── Request 1 ──►  Server
        ─── Request 2 ──►
        ─── Request 3 ──►
        ◄── Response ────

Useful for: batch upload, sensor data, large file upload.

4. Bidirectional Streaming — Both sides send independent streams simultaneously.

  Client ─── Request 1 ──►  Server
        ─── Request 2 ──►
        ◄── Response 1 ──
        ─── Request 3 ──►
        ◄── Response 2 ──
        ◄── Response 3 ──

Useful for: chat, real-time collaboration, streaming analytics.

Unary vs Streaming: Latency Difference

Unary (one request per item):
  ┌──┐  ── Req 1 ──►  ┌──┐
  │C L│  ◄── Res 1 ──  │S  │
  │L I│  ── Req 2 ──►  │E  │  (N round trips = 2N network delays)
  │I E│  ◄── Res 2 ──  │R  │
  │E N│  ── Req 3 ──►  │V  │
  │N T│  ◄── Res 3 ──  │ER │
  └──┘                  └──┘

Streaming (single connection, multiplexed):
  ┌──┐  ──── Req 1 ────►  ┌──┐
  │C L│  ──── Req 2 ────►  │S  │
  │L I│  ◄─── Res 1 ────  │E  │  (1 RTT setup + stream)
  │I E│  ──── Req 3 ────►  │R  │
  │E N│  ◄─── Res 2 ────  │V  │
  │N T│  ◄─── Res 3 ────  │ER │
  └──┘                      └──┘

With unary, N requests = N separate HTTP/2 round trips. With streaming, the connection is established once and messages flow without per-request overhead.

Why HTTP/2 Matters

gRPC multiplexes many RPC calls over a single TCP connection. No head-of-line blocking. No connection storms when a service restarts.

Real-World gRPC

gRPC is the default RPC framework for:

• Microservices — standard internal communication (e.g., Netflix, Square, Lyft)
• Kubernetes APIs — kubectl talks to the API server via gRPC
• etcd — distributed key-value store uses gRPC for all client communication
• Envoy proxy — uses gRPC for xDS configuration APIs

service UserService {
  // Unary
  rpc GetUser (GetUserRequest) returns (User);
  
  // Server-streaming: get all users matching a filter
  rpc ListUsers (ListUsersRequest) returns (stream User);
  
  // Bidirectional streaming: real-time user updates
  rpc WatchUsers (stream UserAction) returns (stream UserEvent);
}

Check Your Understanding

1. A ride-sharing app needs to send real-time GPS coordinates from driver to server every 100ms. Which gRPC streaming type should they use?

2. Why does HTTP/2 multiplexing reduce the “thundering herd” problem when a microservice restarts?

3. You have an existing REST API. Should you rewrite it in gRPC? When is it worth the migration cost?

The “So What?”

gRPC’s streaming model isn’t just a performance optimization — it enables entirely new patterns: real-time dashboards, streaming ML inference, live collaboration, event sourcing. If you’re building microservices today, gRPC is the default choice for internal communication. REST still wins for external/public APIs where browsers and mobile clients are the consumers (but even that is changing with gRPC-Web and Connect).

✏️ Exercises

Exercises: Architectural Models & RPC

Exercise 1: Architecture Choice

A team is building a file-sharing application for 100,000 users. Files are read-heavy (mostly downloads), users are geographically distributed, and there is no budget for centralized infrastructure.

1. Which architectural model (client-server, P2P, multi-tier, hybrid) would you recommend?
2. What specific design decisions would you make to handle the read-heavy workload?
3. What are the top three problems you’d need to solve?

Exercise 2: RPC Call Failure Analysis

A client calls deductBalance(userID: "u42", amount: 50.00) via RPC. The client stub sends the request to the server. For each scenario below, state what happens and whether the client’s balance is correct:

1. The client stub marshals the request and sends it. The server receives it, unmarshals, calls the function (which deducts $50 from the DB), but the server crashes before sending the response.
2. The server receives the request, processes it, and sends the response. The response is lost in the network. The client times out and throws an exception.
3. The client sends the request. The server processes it and sends the response. The client receives the response. Everything works — but the network duplicates the request and the server processes it twice.

Exercise 3: Protobuf Field Evolution

You have this protobuf schema deployed in production:

message Order {
  string order_id = 1;
  string user_id = 2;
  float total = 3;
}

You want to add a string coupon_code = 4 field. Some old server instances still running don’t know about field 4.

1. Will old servers crash when they receive a message with coupon_code set?
2. A client built from the old schema processes a message that has coupon_code. What does the client see?
3. What happens if you later delete field 3 (total) and reuse its number for a new int64 total_cents = 3?