This is the normal write path for a Raft replicated state machine under a stable leader. A real implementation also handles terms, heartbeats, retries, log repair, membership changes, and snapshots.
1. Reach the leader
The client sends a command to the current leader. A follower may redirect the client or return information about the leader. If the leader has changed, the client retries according to the system's protocol.
2. Append locally and replicate
The leader appends an entry to its log, then sends AppendEntries RPCs to followers. Followers check that the preceding log entry matches before accepting new entries. A follower may reject the append when its log diverges; the leader backs up and retries with earlier entries to repair it.
3. Commit under the protocol rule
Once the entry is replicated to a majority under Raft's term and log rules, the leader advances its commit index. Acknowledgement from one follower alone is not enough in a cluster of more than two nodes. The majority condition helps ensure a later leader can preserve committed entries.
4. Apply and respond
The leader applies committed entries in order to its deterministic state machine and can then respond to the client. Followers apply the same committed sequence. A client timeout can leave the command's outcome uncertain, so application commands may still need idempotency semantics.
This trace follows Raft's core idea; it does not imply that every distributed database uses Raft. See the Raft paper for the safety rules and assumptions.