Tags: grpc, protobuf, http2, microservices, rpc, networking

Level: intermediate

TL;DR: High-performance, open-source RPC framework using HTTP/2 transport and Protocol Buffers for typed contracts, multiplexing, and bi-directional streaming.

Key concepts

Contract-first API architecture defined via .proto interface definition files.

Binary serialization powered by Protocol Buffers yields compact payloads and fast parsing.

Built strictly on HTTP/2, leveraging binary framing, multiplexing, and header compression (HPACK).

Native support for four communication modes: unary, server streaming, client streaming, bi-directional streaming.

Strongly typed client stubs and server skeletons generated automatically via protoc.

Default communication uses trailers to convey status codes (grpc-status) and error details.

Built-in primitives for deadline propagation, request cancellation, and authentication interceptors.

L4 vs L7 load balancing: standard TCP balancers break because multiplexed HTTP/2 connections persist.

Typical questions and ready answers

Q: What is the fundamental difference between gRPC and REST over HTTP/1.1?R: gRPC relies on strict schema contracts via Protocol Buffers and binary serialization over multiplexed HTTP/2 streams. In contrast, REST typically exchanges text-based JSON over HTTP/1.1 with distinct TCP handshakes per connection.

Q: How do you handle load balancing with gRPC clients?R: Standard L4 load balancers send all requests to one backend because HTTP/2 keeps connections open; I resolve this using client-side balancing or an L7 proxy like Envoy.

Q: What is the role of deadlineline propagation in distributed gRPC calls?R: A client sets an execution timeout that propagates across downstream service boundaries via metadata headers, allowing downstream services to abort immediately if the deadline expires.

Q: When would you choose REST over gRPC?R: I pick REST for public-facing client-to-backend APIs requiring broad browser compatibility, simple caching, or human-readable payloads without custom tooling.

Pitfalls and common mistakes

Using standard L4 round-robin balancers, causing all traffic to pin to a single server instance.

Forgetting to configure client keepalive pings, causing silent disconnects through firewalls and NAT gateways.

Re-creating ClientChannel instances per request instead of reusing a shared long-lived channel.

Neglecting deadlineline propagation, leading to thread and resource exhaustion during downstream outages.

Breaking field compatibility by altering existing Protobuf tag numbers or reordering wire types.

Directly exposing gRPC to public browser clients without a specialized proxy layer like grpc-web.

Snippets and commandsProtocol Buffers

```syntax = "proto3";

package order.v1;

service OrderService {

rpc GetOrder (OrderRequest) returns (OrderResponse);

rpc StreamOrders (OrderRequest) returns (stream OrderResponse);

}

message OrderRequest {

string order_id = 1;

}

message OrderResponse {

string order_id = 1;

string status = 2;

double total_amount = 3;

}

Compile proto definitions into Go code and gRPC stubs

protoc --proto_path=. --go_out=paths=source_relative:. --go-grpc_out=paths=source_relative:. order.proto

Inspect and invoke gRPC endpoints via CLI using reflection

grpcurl -plaintext localhost:50051 list

grpcurl -plaintext -d '{"order_id": "123"}' localhost:50051 order.v1.OrderService/GetOrder

```

To review

[ ] Implement client-side connection pooling and interceptor chaining

[ ] Configure Envoy proxy for gRPC-Web to backend gRPC transcoding

[x] Protocol Buffers backward and forward compatibility rules

[x] Core differences between unary and bidirectional streaming

References

gRPC Official Documentation (grpc.io/docs)

Protocol Buffers Language Guide (protobuf.dev)

RFC 7540 - Hypertext Transfer Protocol Version 2 (HTTP/2)