[philsnow]

> a tee loadbalancer for gRPC, forwarding the same requests to both A and B backend pools, but only returning results from A

I would call that a "(live) traffic replayer" rather than a load balancer. "load balance" implies to me that the upstream traffic is divvied up among the downstream sinks, not that the upstream traffic gets copied to multiple downstreams.

[puzzle]

It's a load balancer, because, typically, there is more traffic than a single server can handle. That's why I mention pools: it sends traffic to one of {A1, A2, ...} and one of {B1, B2, ...}. Using your terminology, that instance of the load balancer will take the upstream traffic and divvy it up twice, among two separate groups of downstream pools. A load balancing tee proxy/LB is also useful where B is a new implementation that is supposed to handle more traffic. You could e.g. bring up 10 A replicas and 5 B replicas and compare their performance metrics. That setup is closer to reality than one instance of A and one of B (if you want to test soft stickiness, for example).

Anything at Google that does not support load balancing is doomed to melt fairly quickly.