gRPC & Protocol Buffers

Why This Comes Up in Interviews

Any system design with internal microservice communication should consider gRPC. Interviewers want to hear:

• When to use gRPC vs REST
• How Protocol Buffers achieve 10x smaller payloads
• How streaming enables real-time data flow between services
• Trade-offs: performance vs ecosystem/debugging complexity

How gRPC Works

%%{init: {'theme': 'base', 'themeVariables': {'fontSize': '13px', 'fontFamily': 'Inter, -apple-system, sans-serif'}, 'flowchart': {'nodeSpacing': 30, 'rankSpacing': 50, 'padding': 12, 'curve': 'basis'}, 'sequence': {'actorMargin': 60, 'messageMargin': 40}, 'class': {'padding': 12}}}%%
flowchart LR
    subgraph Client
        C[Client Code] --> CS[Generated Stub]
        CS --> Ser1[Protobuf Serialize]
    end

    Ser1 -->|HTTP/2 binary frame| Net[Network]

    subgraph Server
        Net --> Deser[Protobuf Deserialize]
        Deser --> SS[Generated Server Interface]
        SS --> S[Server Implementation]
    end

    style Net fill:#3b82f6,color:#fff

The flow:

1. Define service contract in .proto file (schema-first design)
2. Generate client stub and server interface in any language
3. Client calls stub method like a local function
4. Stub serializes to Protobuf binary, sends over HTTP/2
5. Server deserializes, executes, returns response the same way

Protocol Buffers — Why 10x Smaller

// .proto definition
message User {
  int64 id = 1;
  string name = 2;
  string email = 3;
  repeated string roles = 4;
}

JSON (95 bytes):

{"id":12345678,"name":"Alice","email":"alice@example.com","roles":["admin","user"]}

Protobuf (38 bytes): Binary encoding — field numbers instead of names, varint encoding for integers, no delimiters.

Four Communication Patterns

%%{init: {'theme': 'base', 'themeVariables': {'fontSize': '13px', 'fontFamily': 'Inter, -apple-system, sans-serif'}, 'flowchart': {'nodeSpacing': 30, 'rankSpacing': 50, 'padding': 12, 'curve': 'basis'}, 'sequence': {'actorMargin': 60, 'messageMargin': 40}, 'class': {'padding': 12}}}%%
flowchart TD
    subgraph "gRPC Patterns"
        U[Unary<br/>1 request → 1 response]
        SS[Server Stream<br/>1 request → N responses]
        CS[Client Stream<br/>N requests → 1 response]
        BD[Bidirectional Stream<br/>N requests ↔ N responses]
    end

    style U fill:#3b82f6,color:#fff
    style SS fill:#22c55e,color:#fff
    style CS fill:#f59e0b,color:#fff
    style BD fill:#8b5cf6,color:#fff

Service Definition Example

syntax = "proto3";

service OrderService {
  // Unary
  rpc GetOrder(GetOrderRequest) returns (Order);

  // Server streaming
  rpc ListOrders(ListOrdersRequest) returns (stream Order);

  // Client streaming
  rpc BatchCreateOrders(stream CreateOrderRequest) returns (BatchResult);

  // Bidirectional streaming
  rpc OrderUpdates(stream OrderSubscription) returns (stream OrderEvent);
}

message Order {
  string id = 1;
  string customer_id = 2;
  repeated LineItem items = 3;
  OrderStatus status = 4;
  google.protobuf.Timestamp created_at = 5;
}

enum OrderStatus {
  ORDER_STATUS_UNSPECIFIED = 0;
  PENDING = 1;
  CONFIRMED = 2;
  SHIPPED = 3;
  DELIVERED = 4;
}

HTTP/2 Advantages

gRPC vs REST — When to Use Which

Production Considerations

Load Balancing

gRPC uses long-lived HTTP/2 connections. Standard L4 load balancers don't work well — all requests go to the same backend.

Solutions: - L7 load balancer (Envoy, Linkerd) — inspects HTTP/2 frames, balances per-request - Client-side load balancing — client discovers backends, round-robins itself - Service mesh (Istio) — sidecar proxy handles routing

Error Handling

gRPC uses status codes (not HTTP status codes):

Deadlines & Timeouts

Client sets deadline: 2 seconds
→ Service A (500ms) → Service B (800ms) → Service C (???)

Remaining deadline propagates through the call chain. If Service C gets 700ms remaining and can't finish — it returns DEADLINE_EXCEEDED immediately instead of wasting resources.

Interview Cheat Sheet