Skip to content

Leader and followers in a Queen cluster

The leader orders every write; followers parse their own clients' requests and answer from their own copy. Reads wait for what was committed, and a SIGTERM hands leadership over.

Updated View as Markdown

A raft group has one leader. The other nodes are followers, and every node has a full copy of the data.

The leader orders all the writes. A follower is not idle: it reads the requests of its own clients, prepares each one, and sends the leader only the prepared command. When the write is committed, the follower answers its client from its own copy. So the leader spends its time ordering and writing, not parsing JSON.

A client sends a push to a follower. The follower parses it and prepares the command, and sends the leader only the prepared command. The leader orders it into an entry, and once a majority has it on disk the entry is committed. The follower applies the entry to its own copy and answers its client from there. The leader never parses the client's JSON.A client sends a push to a follower. The follower parses it and prepares the command, and sends the leader only the prepared command. The leader orders it into an entry, and once a majority has it on disk the entry is committed. The follower applies the entry to its own copy and answers its client from there. The leader never parses the client's JSON.
A follower does the work of its own clients.

A client can talk to any node. A read waits until that node has applied everything that was committed when the read started, so nobody reads behind a write they were already told about.

If the leader stops with SIGTERM, it hands its role to the most up-to-date follower, in a fraction of a second. If it crashes, the others wait one to two seconds and elect a new leader.

Navigation

Type to search…

↑↓ navigate↵ selectEsc close