How does ScyllaDB guarantee strongly consistent schema changes using Raft?

Older versions of ScyllaDB (and Cassandra) propagated schema changes via gossip, an eventually-consistent protocol, which could momentarily leave different nodes with slightly different views of the schema during a rollout, an acceptable risk for schema but not ideal. ScyllaDB has since adopted Raft, a leader-based consensus protocol, specifically for schema and cluster topology changes.

Under Raft, schema changes are proposed to a Raft group spanning the cluster's nodes; a leader replicates the change as a log entry, and it's only considered committed once a majority of the group has durably persisted it. Every node applies committed log entries in the same order, which guarantees that at any point every node either has the old schema or the new one - never an inconsistent in-between state - unlike gossip's best-effort convergence. The same Raft-based mechanism is used for topology changes (adding/removing nodes, tablet migrations), which is what makes those operations safer and faster to reason about than the older gossip-driven approach.