[Paper] WOC: Dual-Path Weighted Object Consensus Made Efficient

Source: arXiv - 2512.20485v1

Overview

The paper introduces WOC (Weighted Object Consensus), a new dual‑path consensus protocol that simultaneously exploits node heterogeneity and operation independence. By routing independent requests through a lightweight “fast path” and contentious requests through a traditional “slow path,” WOC delivers up to 4× higher throughput on realistic workloads while keeping latency comparable to existing systems.

Key Contributions

• Dual‑path design that separates independent and conflicting operations, allowing the system to pick the optimal consensus strategy on a per‑request basis.
• Object‑specific weighted quorums for the fast path, enabling one‑round‑trip commits while respecting differences in node capacity (CPU, network, storage).
• Leader‑coordinated slow path that falls back to a classic weighted‑quorum consensus when operations touch the same object, preserving safety under contention.
• Comprehensive evaluation showing up to 4× throughput improvement over Cabinet on workloads with >70 % independent objects, with no loss of performance under high contention.
• Implementation‑level details (message flow, failure handling, and re‑balancing of node weights) that make the protocol practical for real‑world distributed services.

Methodology

1. Workload classification – Each client request is examined for its target object(s). If the request accesses an object that no other in‑flight request is touching, it is marked independent; otherwise it is conflicting.
2. Fast path – Independent requests are broadcast to a weighted quorum of replicas that store the target object. The quorum size is computed from per‑node weights (e.g., CPU speed, network bandwidth). Once a majority of weighted votes is collected, the operation commits in a single network round‑trip (client → replicas → client).
3. Slow path – Conflicting requests are funneled to a designated leader. The leader runs a classic weighted‑quorum consensus (similar to Cabinet) that may involve multiple round‑trips to resolve ordering and ensure linearizability.
4. Dynamic switching – If a fast‑path request later discovers a conflict (e.g., another request started accessing the same object), it is aborted and re‑issued on the slow path. The protocol guarantees that at most one path is active for a given object at any time, preventing split‑brain scenarios.
5. Failure handling – Node failures trigger weight re‑distribution and quorum re‑calculation. The leader can be re‑elected without halting the fast path for unrelated objects.

The authors built a prototype in Go, integrated with a key‑value store, and ran experiments on a 12‑node cluster with heterogeneous hardware (mix of high‑end and low‑end machines).

Results & Findings

• Fast path dominates when >70 % of operations target distinct objects, delivering near‑linear scaling with added nodes.
• Slow path performance matches Cabinet, confirming that the fallback does not introduce extra overhead.
• Weight awareness lets faster nodes carry a larger share of the quorum, improving overall latency without sacrificing safety.
• Graceful degradation: when the workload becomes highly contended, WOC automatically shifts most traffic to the slow path, preserving correctness and avoiding catastrophic throughput loss.

Practical Implications

• Micro‑service back‑ends that store many independent entities (e.g., user profiles, IoT device states) can adopt WOC to cut latency in half while handling heterogeneous cloud VMs or edge nodes.
• Hybrid cloud deployments benefit from weighted quorums: powerful data‑center nodes can shoulder more of the consensus load, while cheaper edge nodes still participate for durability.
• Database sharding strategies can be simplified—rather than manually assigning hot shards to strong machines, WOC’s fast path automatically routes hot‑object operations to a weighted quorum that includes the strongest replicas.
• Developer ergonomics: the protocol is transparent to client code; developers only need to label objects as “sharded” (the default) and let the library decide the path, reducing the need for custom leader election or lock services.
• Fault‑tolerant services (e.g., leaderboards, real‑time analytics) can maintain high throughput even when a subset of nodes is under‑provisioned or experiencing network jitter, because the fast path tolerates weight imbalances.

Limitations & Future Work

• Workload classification overhead: detecting conflicts requires tracking in‑flight object accesses, which may become a bottleneck for extremely high request rates.
• Static weight assignment: the prototype uses manually configured node weights; dynamic weight adaptation based on runtime metrics is left for future research.
• Partial replication: WOC assumes each object is fully replicated across all nodes; extending the design to selective replication or erasure‑coded storage would broaden applicability.
• Security considerations: weighted quorums could be vulnerable to weight‑inflation attacks; the authors suggest integrating authentication and weight verification mechanisms.
• Broader evaluation: experiments were limited to a 12‑node cluster; scaling to hundreds of nodes and testing under real‑world network partitions remain open challenges.

Authors

• Tanisha Fonseca
• Gengrui Zhang

Paper Information

• arXiv ID: 2512.20485v1
• Categories: cs.DC
• Published: December 23, 2025
• PDF: Download PDF