Ticketing RPC Types
The tag in a frame decides the RPC type. Every payload is an openraft type serialized with postcard.
| tag | Name | Request payload | Response payload | Role |
|---|---|---|---|---|
1 | Vote | VoteRequest | VoteResponse | Leader election — a candidate asks other nodes for their vote |
2 | AppendEntries | AppendEntriesRequest | AppendEntriesResponse | Log replication + heartbeat — the leader propagates replicated commands to followers |
3 | FullSnapshot | a (Vote, SnapshotMeta, snapshot_bytes) tuple | SnapshotResponse | Sends the entire snapshot to a node that's fallen behind |
- Vote — when the leader dies, a node whose heartbeat has stopped becomes a candidate and requests votes; the node that wins a majority becomes the new leader.
- AppendEntries — the leader carries lock commands to commit as log entries. An AppendEntries with no entries is the heartbeat — there's no separate heartbeat message.
- FullSnapshot — sends the entire current state to a node too far behind to catch up via the log (or one that just joined). Sent whole, in a single frame, with no streaming.
Flow — When the Leader Dies
Node A
Node B
Node C
detects the leader's heartbeat is gone → becomes a candidate
Vote · requesting a vote
Vote · requesting a vote
yes
majority including itself → new leader
AppendEntries (no entries = heartbeat)
AppendEntries (no entries = heartbeat)
consensus RPC (Raft)
The moment the newly elected leader's first heartbeat arrives, the cluster is back to normal service — the total gap is usually 0.5-1 second. See Replicated Commands for the AppendEntries (log replication) flow during normal operation.
Terminology
- log replication — the leader turns its decided commands into an ordered log and has followers record it verbatim. Applying the same log in the same order brings every node to the same state.
- heartbeat — a periodic "I'm alive" signal. When it stops, followers conclude the leader has died and start an election.