Title: Integrating 2PC with Consensus for Fast Replication
Authors: Yan Chen (Shanghai Jiao Tong University & Tsinghua University); Xinyi Yu, Shengyun Liu, Ruofan Xiong, Tianjing Xu(Shanghai Jiao Tong University); Yongwei Wu (Tsinghua University); Yiming Zhang (Shanghai Jiao Tong University)
Introduction
This paper studies how to make state machine replication fast without giving up fault tolerance. Traditional consensus protocols such as Raft and Multi-Paxos require two RTTs, which is too slow for latency-sensitive systems. Existing fast-path designs like CURP-Q reduce latency, but they still couple low latency with fault handling, which adds architectural complexity and overhead even in the common fault-free case. The paper argues that this coupling is the real problem, and that normal-case execution should not pay the cost of consensus when no conflict or failure exists.
Key idea and contribution
The core idea of xRaft is to decouple fast execution from fault tolerance by combining client-coordinated two-phase commit with Raft. In the Fast mode, the client broadcasts requests directly to replicas, and updates finish in one RTT when there are no conflicts or failures. In the Consensus mode, xRaft falls back to ordinary Raft for ordering and recovery. This makes the common case lightweight while still preserving correctness under adverse conditions.
The contribution is a hybrid replication framework that switches safely and adaptively between the two modes. Unlike CURP-Q, xRaft does not require every request to go through both fast and slow paths. It also avoids heavy common-case machinery such as dependency graphs, special clocks, or special hardware. The authors implement xRaft on top of braft and EtcdRaft with minimal invasive changes, showing that the design is practical rather than purely theoretical.
Evaluation
The evaluation shows that xRaft outperforms Raft, Paxos, and CURP-Q across microbenchmarks, mode-switching tests, production workloads, and YCSB KV tests. On YCSB workload A with 2% conflicts, xRaft reaches over 37 ktps, about 27% higher than CURP-Q and 12% higher than EPaxos. In the EDA workload, xRaft’s latency is 118 microseconds with one client thread and 119 microseconds with eight threads, while Raft rises from 148 microseconds to 193 microseconds. This result is significant because it shows that a system can get fast common-case performance without paying the usual complexity tax of fast-consensus protocols.
Personal thoughts
I like this paper because its design principle is simple and sharp: do not use consensus when you do not need it. That separation makes the protocol easier to reason about and seems much more aligned with real workloads, where conflicts are often rare. I also appreciate that the authors validated correctness with TLA+ and implemented the system on real Raft codebases.
What I find less satisfying is that the fast path still depends on a favorable execution environment, so the benefit depends on how often the system stays in the conflict-free regime. The interesting open question is how far this idea can scale to more complex replicated services, especially when conflicts are more frequent or the system spans multiple partitions and datacenters. It would also be interesting to see whether similar “fast path + fallback” designs can be generalized beyond Raft-style replication.