SYSTEM Cited by 6 sources

gRPC

gRPC is Google-originated (now CNCF) high-performance RPC framework built on HTTP/2 with Protocol Buffers as the default serialization. The key design choice relevant to system design: long-lived, multiplexed HTTP/2 connections — many concurrent requests flow over one TCP connection instead of opening/closing per call.

Why gRPC breaks L4 load balancers

HTTP/2's long-lived connection is a correctness/perf win for the protocol (no per-request TCP + TLS handshake) but a problem for Layer 4 load balancers (systems/kube-proxy):

• L4 LB picks a backend once per TCP connection.
• gRPC keeps that connection alive for many requests.
• → All requests from that client go to the same backend.
• → Traffic skew: across a fleet, some pods hot-spot while others idle.

The fix is to move load-balancing decisions up to Layer 7, per-request: - concepts/client-side-load-balancing — the client library picks a backend per call. - systems/envoy / service-mesh sidecar — an L7 proxy parses HTTP/2 frames and picks per request.

gRPC itself has a built-in load-balancing API (xds: resolver, round_robin, etc.) that lets the client library subscribe to an xDS control plane and do per-request routing. That's the mechanism Databricks uses via their Armeria-based Scala client on top of a custom xDS server (systems/databricks-endpoint-discovery-service).

Seen in

• sources/2025-10-01-databricks-intelligent-kubernetes-load-balancing — gRPC over HTTP/2 is explicitly the workload that motivated Databricks to build client-side L7 load balancing, because kube-proxy's per-connection selection caused persistent traffic skew.
• sources/2024-10-28-dropbox-robinhood-in-house-load-balancing — Dropbox extended its service-discovery system to speak xDS (per gRPC A27) so Robinhood can drive gRPC clients too. Since gRPC upstream doesn't support endpoint-weight-aware weighted round-robin as of the post's date, Dropbox wrote a custom weighted-RR picker based on earliest-deadline-first scheduling. Generalizable note: EDF yields weighted-RR with lower variance than ticket-bucket approaches when the client library needs to implement its own picker.

• sources/2026-04-08-aws-build-a-multi-tenant-configuration-system-with-tagged-storage-patterns — gRPC used in two distinct roles in the multi-tenant config architecture: (1) internal Order Service → Config Service call path (picked over REST for "high-performance, type-safe communication ... where compatibility with web browsers isn't a requirement"); (2) the refresh RPC endpoint on every Config Service instance, called by the invalidator Lambda to push fresh configuration into in-memory caches (the "zero-downtime configuration updates with gRPC streaming" cited as a headline design decision). Streaming-capable transport makes per-instance push-invalidation tractable without polling.

• sources/2024-09-16-lyft-protocol-buffer-design-principles-and-practices — The .proto files gRPC consumes are themselves a schema-design surface with clarity + extensibility pressures. Lyft Media's post canonicalises five practices (reserve 0 as UNKNOWN; prefer oneof over discriminator-enum + sibling fields; unit-suffix field names; optional label / wrapper types for presence; inline declarative validation via PGV / protovalidate) that apply to every gRPC service definition regardless of transport. First wiki source on protobuf schema design as distinct from protobuf as a wire format.

gRPC amplifies DNS routing problems at CDN-origin scale

The same long-lived connection property that breaks L4 load balancers also amplifies DNS-level routing problems when gRPC traffic flows through a CDN (CloudFront). At 121M mobile devices establishing persistent gRPC connections, Route 53 Weighted routing (1 IP per DNS response) caused all CloudFront edge nodes to route to a single NLB per TTL window. Unlike short-lived HTTP where connections churn and redistribute, gRPC connections accumulated on whichever origin was resolved at establishment time and stayed there for the session lifetime. The result: a DNS misconfiguration that would produce mild unevenness with HTTP caused an 80% error rate with gRPC. See concepts/persistent-connection-amplification and sources/2026-07-15-aws-bitdrift-scaled-121-million-grpc-connections-cloudfront.

gRPC on edge serverless (Cloudflare Workers)

Cloudflare added gRPC support to Workers in August 2026 via two complementary paths:

1. Full bidirectional gRPC via Containers — raw TCP socket passthrough from Spectrum → Worker → Durable Object → Container enables any gRPC server in any language to run at 330+ edge locations with full client/server/bidirectional streaming.

2. Unary + server-streaming via gRPC-web translation — Cloudflare's reverse proxy converts inbound gRPC (HTTP/2 framed) to gRPC-web and outbound gRPC-web back to gRPC, letting Workers serve and call gRPC using @connectrpc/connect without clients needing changes. This gRPC↔gRPC-web conversion has run in Cloudflare's proxy since 2020.

The key architectural constraint: web platform APIs (fetch()) don't expose HTTP/2 frame-level control (stream IDs, per-stream flow control, trailers), which is why the gRPC-web intermediate layer is necessary for the Workers path. The Container path bypasses this by giving the server raw TCP access.

See patterns/grpc-web-transparent-translation and sources/2026-08-03-cloudflare-workers-and-containers-now-support-inbound-tcp-connections-and-grpc.