Raft is a distributed consensus algorithm used when several nodes must agree on shared state. In ScyllaDB, it provides strong ordering for internal changes such as schema and topology updates, replacing an older approach that spread schema changes through gossip. This avoids incompatible concurrent schema views that could otherwise cause query errors. section 8.2.4 section 8.5
Raft is leader-driven. A majority of nodes elect one leader, which handles client requests, coordinates followers, and ensures agreement on a value. This differs from ScyllaDB’s usual leaderless request handling, where any node can service a request. section 8.2.5
Figure 8.9 Raft’s leader appends entries to its log, committing them when a majority of nodes have also acknowledged the append operation.
The leader appends each change to a replicated, append-only log. An entry becomes committed only after a majority of nodes acknowledge the append, giving the cluster a consistent record of accepted changes. section 8.2.5 section 8.5
Raft makes a deliberate availability trade-off for the internal state it protects:
- If the leader goes offline, requests pause while the cluster elects a replacement leader. section 8.2.5
- During a network partition, Raft favors consistency over availability, making the Raft-based subsystem CP under the CAP theorem. section 8.2.5
- This does not reclassify ScyllaDB’s overall design: Raft protects selected internal systems while the broader database remains oriented toward availability and partition tolerance. section 8.2.5
Concurrent schema changes
Two schema changes propagated by gossip could reach nodes in conflicting orders, producing inconsistent schemas and potentially failing queries. Raft instead serializes these internal changes through its leader and commits them after majority acknowledgment, so the cluster proceeds from one agreed state. section 8.2.4 section 8.2.5
