BALLAST: Bandit-Assisted Learning for Latency-Aware Stable Timeouts in Raft

BALLAST: Bandit-Assisted Learning for Latency-Aware Stable Timeouts in Raft Qizhi Wang PingCAP, Data & AI-Innovation Lab Beijing, China qizhi.wang@pingcap.com Abstract Randomized election timeouts are a simple and effective live- ness heuristic for Raft, but they become brittle under long-tail latency, jitter, and partition recovery, where repeated split votes can inflate unavailability. This paper presents BALLAST, a lightweight online adaptation mechanism that replaces static timeout heuristics with contextual bandits. BALLAST selects from a discrete set of timeout “arms” using efficient linear con- textual bandits (LinUCB variants), and augments learning with safe exploration to cap risk during unstable periods. We eval- uate BALLAST on a reproducible discrete-event simulation with long-tail delay, loss, correlated bursts, node heterogeneity, and partition/recovery turbulence. Across challenging WAN regimes, BALLAST substantially reduces recovery time and unwritable time compared to standard randomized timeouts and common heuristics, while remaining competitive on stable LAN/WAN settings. 1 Introduction Leader-based replication systems depend on timely leader re- covery. In Raft, leadership is re-established via leader elec- tion, whose liveness depends critically on election timeouts and failure detection. The standard approach randomizes elec- tion timeouts within a fixed range to reduce split votes and avoid perpetual contention [20]. In modern deployments— geo-distributed clusters, multi-tenant clouds, and Kubernetes environments—network delays are often long-tailed and non- stationary [8]. Under these conditions, fixed timeout ranges can become miscalibrated: too aggressive leads to cascading split votes and term churn; too conservative inflates recovery latency and unwritable time. Motivating observation. In production, operators often “fix” leader-election instability by pushing timeouts upward (e.g., from hundreds of milliseconds to seconds). This can stop elec- tion storms, but it also turns every recovery event into a longer outage window. Worse, the “right” timeout depends on where the cluster runs today (LAN vs. WAN), what the network looks like now (transient congestion), and even which nodes are slow (hardware or noisy neighbors). As a result, timeout config- uration becomes both high-stakes and environment-specific, and the same static setting can oscillate between being too aggressive and too conservative. Goal. We seek an election-timeout mechanism that (i) adapts online to changing network conditions, (ii) is lightweight enough to run in a consensus event loop, and (iii) includes safety valves that prevent catastrophic exploration during turbulence. Key idea. We cast timeout selection as an online deci- sion problem. At each node and term, an agent observes local signals (e.g., heartbeat inter-arrival and election his- tory) and selects a timeout arm from a small discrete set (ag- gressive/moderate/conservative). After an election attempt, the agent receives a delayed reward reflecting success and time-to-recover. We instantiate this with linear contextual bandits (LinUCB) [18] and add (a) non-stationary variants (discounted/sliding-window) and (b) safe exploration via a con- servative fallback policy. Where the idea comes from. BALLAST is inspired by a pragmatic view of consensus engineering: many “hard” avail- ability incidents reduce to miscalibrated thresholds under shift- ing environments. Failure detectors (e.g., Φ accrual [13]) al- ready embody this idea by adapting suspicion to observed ar- rival patterns. We ask: can we apply a similarly lightweight, more directly optimization-driven adaptation to election time- outs, while keeping the Raft protocol unchanged? Contributions. • BALLAST, a lightweight contextual-bandit framework for Raft election timeouts with safe exploration and non- stationary adaptation. • A reproducible evaluation methodology (discrete-event sim- ulation, fault injection, protocol-level logging, CI-based ag- gregation) to study election stability under tail latency and recovery turbulence. • An empirical study showing that BALLAST reduces recovery time and unwritable time relative to randomized timeouts and widely used heuristics, without sacrificing stable-LAN performance. 1 arXiv:2512.21165v1 [cs.LG] 24 Dec 2025 2 Problem Setting and Metrics We focus on Raft leader election liveness (safety remains gov- erned by the original protocol rules [20]). We report both election-process latency and end-to-end recovery. Election latency (process). time_to_leader measures the duration from the start of a candidate election attempt to leader establishment. Recovery time (end-to-end). recovery_time mea- sures the duration of an unwritable interval, which in- cludes waiting for election timeouts and retries. We define writable when a strict majority has recently observed heart- beats from the same leader within a grace window; other- wise the system is considered unwr

This content is AI-processed based on open access ArXiv data.