gRPC

gRPC is Google's open-source RPC framework that uses HTTP/2 for transport and Protocol Buffers for serialization. It enables typed, bidirectional communication between services at a fraction of the latency of JSON over REST. In system design, gRPC is the go-to choice for internal microservice communication where performance matters — it is 5-10x faster than REST/JSON for serialization and supports streaming natively.

Why This Matters

In microservice architectures with dozens of services communicating at high frequency, the overhead of JSON serialization and HTTP/1.1 connection management becomes a bottleneck. gRPC eliminates both problems: Protocol Buffers serialize data to compact binary (10x smaller than JSON), and HTTP/2 multiplexes many requests over a single TCP connection. When Netflix or Google routes millions of inter-service calls per second, those savings compound into real infrastructure cost reductions.

The Building Blocks

• Protocol Buffers: Binary serialization format that defines message schemas in .proto files. The compiler generates typed client and server code in any language. Messages are 3-10x smaller than JSON and parse 5-10x faster.
• HTTP/2 Transport: Multiplexed connections allow hundreds of concurrent RPCs over a single TCP connection. Header compression (HPACK) reduces overhead. Server push enables efficient streaming patterns.
• Service Definition: The .proto file is the single source of truth — it defines service methods, request/response types, and streaming modes. Both client and server generate code from the same .proto, eliminating contract drift.
• Streaming Modes: Four patterns: unary (request-response), server-streaming (one request, many responses), client-streaming (many requests, one response), and bidirectional streaming (both sides send freely).
• Interceptors: Middleware chain for cross-cutting concerns — authentication, logging, metrics, retry logic. Both client-side and server-side interceptors wrap every RPC call without touching business logic.
• Deadlines and Cancellation: Every RPC carries a deadline that propagates across the call chain. If service A calls B calls C with a 500ms deadline, C knows how much time remains and can bail early.

Under the Hood

When a gRPC client calls a method, the request is serialized to compact binary using Protocol Buffers, wrapped in an HTTP/2 frame with metadata (deadlines, auth tokens, tracing headers), and sent over a multiplexed connection. The server deserializes the binary payload into a typed object, executes the handler, and returns the response the same way.

The key performance advantage is the binary encoding. A JSON payload like user_id=12345, name=Alice becomes a 12-byte Protobuf message instead of a 40-byte JSON string. Multiply that difference by millions of RPCs per second and you save gigabytes of bandwidth and CPU cycles spent on parsing. HTTP/2 multiplexing means these millions of RPCs share a handful of TCP connections instead of opening a new one per request.

For streaming, gRPC maintains an open HTTP/2 stream where either side can send messages at any time. This is ideal for real-time feeds, log tailing, or chat — the connection stays open and messages flow as they are produced.

How Companies Actually Do This

Google uses gRPC for virtually all internal service communication. Every Google product — Search, Gmail, YouTube — relies on gRPC for backend service calls. The framework was designed for Google's scale of billions of RPCs per second.

Netflix adopted gRPC for inter-service communication in their Java microservices. The typed contracts reduced integration bugs, and the binary encoding cut network bandwidth by 60% compared to their previous JSON-based approach.

Uber migrated from Apache Thrift to gRPC for their 4,000+ microservices. The native deadline propagation solved their cascading timeout problem, where slow downstream services would consume resources in upstream services.

Common Pitfalls

1. Using gRPC for browser-facing APIs without a gRPC-Web proxy — browsers cannot make raw HTTP/2 requests with trailers
2. Ignoring deadline propagation — without explicit deadline forwarding, a 200ms client timeout can trigger a 30-second downstream call that wastes resources
3. Breaking backward compatibility in Protobuf schemas by reusing field numbers or changing field types instead of adding new fields

Interview Questions Worth Practicing

1. When would you choose gRPC over REST for microservice communication, and when would REST be better?
2. How does gRPC achieve lower latency and smaller payloads than JSON-based REST?
3. Explain how deadline propagation works in gRPC and why it matters for cascading failures.

The Tradeoffs

• Performance vs Debuggability: Binary Protobuf is 5-10x faster than JSON but you cannot read payloads with curl or browser dev tools. Debugging requires Protobuf-aware tooling like grpcurl or Kreya.
• Strong Typing vs Flexibility: Schema enforcement catches integration errors at compile time, but requires code generation, build tooling, and schema registries. REST with JSON is more forgiving for rapid iteration.
• HTTP/2 Requirement vs Compatibility: Multiplexing and header compression reduce latency significantly, but HTTP/2 complicates load balancing (L7 required) and some older proxies do not support it.

How to Explain This in an Interview

Here is how I would explain gRPC in a system design interview:

I start by explaining when I would pick gRPC over REST. For internal microservice communication where latency matters and both sides are controlled by my team, gRPC wins: binary serialization via Protobuf makes payloads 5-10x smaller, and HTTP/2 multiplexing avoids the connection overhead of REST. The .proto file acts as a typed contract — schema mismatches are caught at compile time rather than at 3 AM in production. For streaming use cases like live feeds or bidirectional chat, gRPC's native streaming is a natural fit. But for public-facing APIs where any HTTP client needs to connect, REST with JSON is simpler because every tool speaks JSON natively. I would also mention deadline propagation — gRPC automatically forwards timeout budgets across service calls, which prevents cascading failures.

Related Topics

• REST vs GraphQL
• API Design
• WebSockets
• API Gateway

The Real-World Incident That Made This Famous

Understanding gRPC became critical after multiple high-profile production incidents at major tech companies. When systems handle millions of users, even small misunderstandings about gRPC can lead to cascading failures that cost millions in lost revenue and erode user trust. Companies like Netflix, Google, Amazon, and Meta have all invested heavily in mastering gRPC because they learned the hard way that ignoring it leads to outages.

The key lesson from these incidents: gRPC is not just a theoretical concept — it is a practical skill that separates engineers who build resilient systems from those who build fragile ones. Every major outage report from the past decade involves at least one gRPC-related design decision that was either implemented incorrectly or overlooked entirely during the initial architecture review.

How Senior Engineers Think About This

Senior engineers approach gRPC differently from textbook definitions. Instead of memorizing rules, they build mental models. They ask: "What problem does gRPC solve? When does it fail? What are the alternatives?" This problem-first thinking leads to better design decisions because every system has unique constraints.

When evaluating gRPC in a system design context, experienced engineers consider the failure modes first. What happens when this component goes down? How does the system degrade? Is the degradation graceful or catastrophic? These questions reveal more about your understanding than any textbook definition.

The key difference between junior and senior engineers when it comes to gRPC: juniors focus on the happy path, while seniors design for what happens when things go wrong. They consider operational cost, team expertise, monitoring requirements, and how the decision will look six months from now when traffic has grown 10x.

Common Interview Mistakes

Mistake 1: Giving a textbook definition without context. Interviewers want to see you connect gRPC to real systems and real problems. Instead of reciting definitions, explain when and why you would use gRPC in the system you are designing.

Mistake 2: Not discussing trade-offs. Every design decision involving gRPC has trade-offs. Discuss what you gain and what you give up. Acknowledge the downsides and explain why the benefits outweigh them for your specific use case.

Mistake 3: Overcomplicating the solution. Start with the simplest approach to gRPC that meets the requirements, then add complexity only when justified. Many candidates jump to complex implementations when a simpler solution would work perfectly.

Production Checklist

• Define clear metrics for measuring the effectiveness of your gRPC implementation
• Set up monitoring and alerting that specifically tracks gRPC-related failures
• Document your gRPC design decisions in Architecture Decision Records (ADRs)
• Test failure scenarios related to gRPC in staging before production deployment
• Review and update your gRPC implementation quarterly as system requirements evolve
• Train new team members on the specific gRPC patterns used in your system
• Establish runbooks for common gRPC-related incidents and recovery procedures

Practical Implementation for .NET Developers

In .NET, gRPC is a first-class citizen. Use dotnet new grpc to scaffold a server. Define services in .proto files and the tooling auto-generates C# interfaces. Implement Greeter.GreeterBase to handle calls. For clients, GrpcChannel.ForAddress creates a typed client with connection pooling. ASP.NET Core hosts gRPC alongside REST on the same port via MapGrpcService<T>(). For inter-service calls, Grpc.Net.Client with SocketsHttpHandler handles multiplexing, retry (via Grpc.Net.ClientFactory), and deadline propagation natively.

ASP.NET Core setup: Create a service class that encapsulates the logic, register it with dependency injection, and inject it into your controllers or minimal API endpoints. The built-in DI container handles lifecycle management.

Entity Framework Core: For database interactions, EF Core provides the ORM layer. Use migrations for schema management and raw SQL for performance-critical queries. Consider Dapper for read-heavy paths where EF Core overhead matters.

Azure integration: If deploying to Azure, leverage managed services — Azure Cache for Redis, Azure SQL, Azure Service Bus, Azure Cosmos DB. These eliminate operational overhead and provide built-in monitoring through Application Insights.

Testing: Use xUnit with Testcontainers for integration tests that spin up real databases in Docker. Mock external dependencies with NSubstitute. The WebApplicationFactory class lets you test your entire HTTP pipeline in-process.

Monitoring: Add Application Insights telemetry to track request latency, dependency calls, and custom metrics. Use structured logging with Serilog to make production debugging possible:

Log.Information("Processing {Operation} for {ResourceId}", operation, resourceId);

This gives you searchable, structured logs in Azure Monitor or Seq.