gRPC
Cheat Sheet
Prime Use Case
Internal microservices communication where low latency, high throughput, and strict type safety are prioritized over human-readability and browser compatibility.
Critical Tradeoffs
- High performance vs. limited browser support
- Strict schema enforcement vs. development flexibility
- Binary efficiency vs. debugging complexity
Killer Senior Insight
gRPC shifts the complexity of networking, serialization, and concurrency from the application layer to the framework, enabling a 'contract-first' architecture that treats remote calls as if they were local function calls.
Recognition
Common Interview Phrases
Common Scenarios
- Internal service-to-service communication in a microservices mesh
- Mobile-to-backend communication for data-intensive applications
- Real-time data streaming services like stock tickers or chat backends
- Sidecar-to-application communication in Kubernetes environments
Anti-patterns to Avoid
- Public-facing APIs intended for third-party developers (REST is standard)
- Simple web applications with no proxy layer (browsers lack full HTTP/2 control)
- Scenarios where human-readable logs and easy curl-based debugging are the primary requirements
The Problem
The Fundamental Issue
The inefficiency and fragility of text-based protocols (like REST/JSON) which suffer from large payload overhead, expensive parsing, and lack of built-in contract enforcement.
What breaks without it
Increased latency due to verbose JSON serialization/deserialization
Runtime crashes caused by schema mismatches between services
Inefficient connection management leading to head-of-line blocking in HTTP/1.1
Why alternatives fail
REST/JSON is text-heavy and lacks a native streaming model
Custom TCP protocols are difficult to maintain and lack cross-language support
GraphQL adds significant query-parsing overhead for simple point-to-point service calls
Mental Model
The Intuition
Imagine calling a function in your code, but instead of executing on your local CPU, it executes on a remote server. You pass typed arguments and receive a typed result without ever manually handling the network sockets or data formatting.
Key Mechanics
Protocol Buffers (Protobuf) for compact binary serialization
HTTP/2 for multiplexing multiple requests over a single TCP connection
Code generation (protoc) to create client stubs and server skeletons
HPACK header compression to reduce metadata overhead
Framework
When it's the best choice
- High-scale internal systems where every millisecond of latency matters
- Polyglot environments where services are written in different languages (Go, Java, C++, etc.)
- Systems requiring complex streaming patterns (client-side, server-side, or bi-directional)
When to avoid
- When the client is a standard web browser (requires gRPC-Web and a proxy like Envoy)
- When the API needs to be easily discoverable and testable via a browser or simple CLI tools
- When the overhead of managing .proto files and code generation is too high for a small team
Fast Heuristics
Tradeoffs
Strengths
- Significant reduction in payload size (up to 10x smaller than JSON)
- Multiplexing allows multiple concurrent requests without head-of-line blocking
- Strongly typed contracts act as a single source of truth
- Built-in support for deadlines, timeouts, and request cancellation propagation
Weaknesses
- Steeper learning curve and complex tooling setup compared to REST
- Binary format is not human-readable, making network sniffing harder
- Load balancing is complex because HTTP/2 connections are long-lived (requires L7 balancing)
- Schema evolution requires strict discipline to avoid breaking changes
Alternatives
When it wins
Public APIs and simple web integrations where ubiquity is more important than performance.
Key Difference
Uses text-based JSON and standard HTTP verbs; stateless and human-readable.
When it wins
Frontend-to-backend communication where clients need to fetch specific, nested data shapes.
Key Difference
Client-driven data fetching with a single endpoint and flexible query language.
When it wins
Legacy systems or specific niches where Thrift's specific serialization formats are preferred.
Key Difference
Similar RPC model but uses a different transport layer and serialization protocol.
Execution
Must-hit talking points
- Mention HTTP/2 multiplexing to solve the Head-of-Line blocking issue found in HTTP/1.1
- Explain how Protobuf uses field numbers to maintain backward and forward compatibility
- Discuss the importance of L7 load balancing (e.g., using Envoy) for gRPC traffic
- Highlight 'Deadlines' as a first-class citizen for cascading failure prevention
Anticipate follow-ups
- Q:How do you handle load balancing when gRPC keeps TCP connections open indefinitely?
- Q:What is the strategy for versioning Protobuf files without breaking existing clients?
- Q:How does gRPC-Web bridge the gap for browser-based clients?
- Q:How do you implement interceptors for cross-cutting concerns like logging and auth?
Red Flags
Using a standard L4 (TCP) load balancer for gRPC traffic.
Why it fails: gRPC uses long-lived HTTP/2 connections. An L4 balancer will send all requests from one client to one server instance, leading to massive hotspots.
Renaming or renumbering fields in a .proto file.
Why it fails: Protobuf relies on field numbers for serialization. Changing them breaks binary compatibility, causing deserialization failures in production.