What are common gRPC best practices and pitfalls?
Master gRPC best practices: reuse channels, set deadlines, evolve protobuf safely and stream large data — plus the common pitfalls to avoid.
Expected Interview Answer
Good gRPC practice means reusing long-lived channels, always setting deadlines, versioning protobuf fields carefully, and streaming large data — while avoiding pitfalls like per-call channels, missing timeouts, and breaking schema changes.
Create one channel per target and share it, since channels are expensive and manage connection pools and load balancing. Always attach deadlines and handle cancellation so slow calls do not pile up. Evolve .proto files additively: never reuse or renumber field tags, and reserve removed ones. Use streaming for large or continuous payloads instead of huge unary messages, secure channels with TLS, and surface rich status codes with details rather than swallowing errors.
- Stable performance via reused channels
- Backward-compatible protobuf evolution
- Predictable latency from mandatory deadlines
- Efficient transfer of large data via streaming
- Clear error handling with typed status codes
AI Mentor Explanation
Reusing a gRPC channel is like keeping the same set batting partnership going rather than sending a new pair out for every single run. Rebuilding a channel per call is the wasteful equivalent of fresh pads and gloves each ball. Reserving retired protobuf field numbers is like retiring a jersey number so no future player is confused with the legend who wore it.
Step-by-Step Explanation
Step 1
Reuse channels
Create one channel per target endpoint and share it across the app; do not open one per request.
Step 2
Always set deadlines
Attach a deadline to every RPC and handle cancellation to bound latency.
Step 3
Evolve protobuf additively
Add new field numbers, never renumber or reuse tags, and reserve removed ones.
Step 4
Stream large or continuous data
Use client, server, or bidirectional streaming instead of oversized unary messages.
Step 5
Secure and observe
Enable TLS, propagate metadata, and return rich status codes with details for good error handling.
What Interviewer Expects
- Why channels should be long-lived and reused
- Additive, backward-compatible protobuf evolution
- Importance of deadlines on every call
- When to prefer streaming over large unary messages
- Proper use of status codes, TLS and metadata
Common Mistakes
- Creating a new channel per request
- Renumbering or reusing protobuf field tags
- Omitting deadlines and letting calls hang
- Stuffing huge payloads into one unary message
- Swallowing errors instead of returning typed status codes
Best Answer (HR Friendly)
“Good gRPC habits include keeping one shared connection open, always setting a time limit on calls, and changing the message format carefully so old and new versions still work together. The big mistakes are opening a new connection every time and making changes that break older clients.”
Code Example
message User {
string id = 1;
string name = 2;
reserved 3; // old 'age' field removed, tag never reused
reserved "age";
string email = 4; // new field added with a fresh tag
}Follow-up Questions
- Why is creating a channel per request harmful?
- How do you remove a protobuf field safely?
- When should you choose bidirectional streaming?
- How do gRPC status codes differ from HTTP status codes?
- What metadata should you propagate for tracing?
MCQ Practice
1. What is the recommended way to manage gRPC channels?
Channels are expensive and pool connections; reuse one long-lived channel per target for best performance.
2. How should you remove a protobuf field safely?
Reserving the field number and name prevents its tag from being reused and breaking wire compatibility.
3. Which is a common gRPC pitfall?
Omitting deadlines lets calls hang indefinitely and pile up; every RPC should carry a deadline.
Flash Cards
How many channels should you open per target? — One long-lived, shared channel — never one per request.
How do you retire a protobuf field? — Use 'reserved' for its number and name so the tag is never reused.
When should you stream? — For large or continuous data, instead of a single oversized unary message.
What should every RPC carry? — A deadline, so slow calls are bounded and cancelled predictably.