Operation-Type-Aware Client Routing for Leader-Based Consensus Datastores

Leader-based consensus datastores such as etcd and ZooKeeper are the backbone of modern distributed control planes. Their replication protocols impose a fundamental asymmetry: writes must be committed through the leader, while linearizable reads require only a lightweight leader confirmation before any member can serve them locally. This asymmetry creates two competing routing goals for clients: spread load evenly across members, and route operations to the member whose protocol role matches the operation. The upstream etcd client uses gRPC's `round_robin` balancer, which distributes reads and writes uniformly across cluster members. This uniform distribution ignores the protocol-role mismatch, adding a forwarding hop for writes and potentially overloading the leader. The paper investigates whether an operation-type-aware client can resolve this tension and improve performance in steady state and under failure.

The authors propose an operation-aware client that pins write operations to the leader and distributes read operations across a healthy read pool of followers. The client monitors latency signals to detect silent degradation of followers and dynamically removes them from the read pool. The evaluation uses a 3-node etcd cluster with an 80/20 read/write mix, running 5 trials for each configuration. The baseline is the upstream etcd client with gRPC's `round_robin` balancer. The same routing rule is also applied to ZooKeeper, which uses the ZAB protocol, to test whether the results generalize beyond etcd's implementation. The key challenge in adaptively discovering this policy is that the leader confirmation round-trip occurs between cluster members, so the client observes only a blended latency signal rather than the decisive coordination cost directly. The routing decision can be modeled as a simple rule: for each operation $o$, route to the leader if $o$ is a write, otherwise route to a healthy follower in the read pool. The read pool is maintained by monitoring per-follower latency and removing any follower whose latency exceeds a threshold $\tau$ relative to the pool median.