Reading Off The Leader
By default a Raft group serves reads from the leader to guarantee freshness. But the leader can be far away or overloaded. Follower reads let nearby follower replicas serve reads, reducing latency and spreading load.
The Staleness Tradeoff
A follower may lag slightly behind the leader. To serve a correct read it must answer as of a timestamp it has fully applied.
- The client requests data as of a slightly past timestamp.
- A follower that has applied all writes up to that timestamp can answer safely.
- The result is consistent as of the past, not the live present.
This is ideal for read heavy, slightly stale tolerant workloads like dashboards or product catalogs.
Closed Timestamps
The leader periodically publishes a closed timestamp, promising no new writes will be committed below it. Followers track this so they know how far in the past they can safely serve without contacting the leader.
Key idea
Follower reads serve consistent slightly stale data from nearby replicas using closed timestamps, cutting latency and offloading the leader.