4 / 4 REST, gRPC, GraphQL & Serialization

One Replica Gets Everything

Six replicas of a gRPC service sit behind a TCP (layer 4) load balancer. Clients hold long lived channels, and one replica receives the overwhelming majority of RPCs while the newly scaled up replicas stay idle. What is happening?

A

The balancer is hashing on the HTTP/2 :authority pseudo header, which every client sets to the same value

B

HTTP/2 multiplexes every RPC over one long lived TCP connection, so an L4 balancer spreads connections rather than calls

C

gRPC channels enable sticky sessions by default, pinning each client to whichever replica answered its first call for the channel's lifetime

D

Protobuf payloads are small enough that the balancer's least connections algorithm sees near identical counts and cannot distinguish the backends