Problem
gRPC is powerful but misused: huge messages, no deadlines, no versioning, tight coupling. Need patterns for production.
distribution-communicationestablished · medium operational burden
gRPC Patterns & Best Practices
Also known as: grpc, protobuf, rpc, grpc-gateway, connectrpc
Intent
Design efficient, evolvable gRPC services: unary, streaming, errors, versioning, gateway, testing.
Forces
- •Performance: binary, HTTP/2, multiplexing
- •Contract-first: protobuf schema, codegen
- •Streaming: server, client, bidirectional
- •Evolution: field numbers, reserved, packages
Solution
✓ When to Use
- •Internal service-to-service (low latency, high throughput)
- •Polyglot microservices (codegen per language)
- •Streaming required (real-time, bulk)
- •Contract-first development
✗ When Not to Use
- •Public APIs (REST/GraphQL better)
- •Simple CRUD (REST simpler)
- •Team not ready for protobuf/codegen
- •Browser clients (ConnectRPC or gateway needed)
Pros
- +Performance: binary, HTTP/2, multiplexing
- +Contract: schema-first, codegen, breaking detection
- +Streaming: native server/client/bidi
- +Deadlines: built-in cancellation
Cons
- −Complexity: protobuf, codegen, HTTP/2
- −Debugging: binary, need tools (grpcurl, Evans)
- −Browser: needs gateway (ConnectRPC, grpc-gateway)
- −Evolution: field numbers, reserved, packages
Cost Profile
Infrastructure
Low — HTTP/2, standard ports
Operational
Medium — deadlines, retries, observability
Cognitive
High — protobuf, streaming, versioning
Failure Modes
No deadline: hung calls, resource exhaustion
Large messages: >4MB frames, memory pressure
Field number reuse: silent corruption
Deadline too short: false failures
Streaming backpressure: client overwhelms server
Real-World Examples
Alternatives
- rest
- graphql
- tRPC
- async-messaging
- webhooks
Related Patterns
- api-design
- api-versioning
- grpc-gateway
- connectrpc
- protobuf
- deadlines
- streaming
Competency Domains
distribution communicationdeploymentreliability opseconomics evolutiondata state