Consensus Algorithm

The guarantee that nothing bad will ever happen. In consensus terms, safety means that no two correct nodes will ever decide on different values for the same sequence slot. This is a non-negotiable, absolute property.

• Validity: A decided value must have been proposed by some node; the algorithm cannot fabricate data.
• Agreement: All non-faulty nodes eventually output the same value for a given decision instance.
• Violation Example: Two Workflow Engines assigning the same exclusive Distributed Lock to different agents, causing a collision in a narrow warehouse aisle.

The guarantee that something good will eventually happen. Liveness ensures the system continues to make progress and does not stall indefinitely, even in the face of partial failures.

• Termination: Every correct node eventually decides on some value; the algorithm cannot deadlock.
• Fault Tolerance: The system must continue operating as long as a majority (quorum) of nodes are healthy and can communicate.
• Practical Impact: A Fleet Management System (FMS) must continue assigning new tasks to idle robots even if the node hosting the Agent Driver for a parked forklift crashes.

The specific class of failures a consensus algorithm is designed to withstand. The choice of model fundamentally dictates the algorithm's complexity and performance.

• Crash Fault Tolerance (CFT): Assumes nodes simply stop working and remain silent. Simpler to implement and sufficient when security is not the primary concern. Raft is a classic CFT algorithm.
• Byzantine Fault Tolerance (BFT): Assumes nodes can behave arbitrarily, including sending malicious or contradictory messages. Required for high-security, trustless environments. PBFT is a foundational BFT protocol.
• Orchestration Context: For a private fleet operating behind a firewall, CFT is usually adequate. A swarm of drones operating in a contested environment would require BFT.

The mechanism by which a cluster dynamically selects a single node to act as the primary proposer of new log entries. This simplifies the consensus process by serializing all proposals through one authority.

• Term Limits: A leader serves for a bounded period called a term. A new election is triggered if the leader's Heartbeat Mechanism times out.
• Quorum: A candidate must receive votes from a strict majority of the cluster to become leader, preventing split-brain scenarios.
• Role in Orchestration: The elected leader node is typically the one that serializes all writes to the Agent Registry, ensuring that a new robot's Capability Discovery record is added in a globally consistent order.

The process of durably recording an ordered sequence of commands across a majority of nodes. This replicated log is the core state machine that makes a distributed system consistent.

• Append-Only: Entries are only ever added to the end of the log. Once committed, an entry is immutable.
• Committed vs. Uncommitted: An entry is committed once a majority of nodes have acknowledged durably storing it. Only committed entries are applied to the application's state machine.
• State Machine Replication: The same sequence of committed commands, applied in the same order on every node, guarantees that all nodes arrive at the same final state—the definition of a State Synchronization mechanism.

A leader-based consensus algorithm designed for understandability, widely used in orchestration middleware to manage replicated state machines. A single leader node receives all client requests and replicates them to follower nodes via append-only logs. If the leader fails, a randomized election timeout triggers a new leader election. Raft guarantees linearizable consistency and tolerates up to (N-1)/2 node failures in a cluster of N nodes. Key mechanisms include log replication, commit index tracking, and term numbers to prevent split-brain scenarios.

A stronger class of consensus protocols that tolerate arbitrary node failures, including malicious behavior and message forgery. Unlike crash-fault tolerant algorithms like Raft, PBFT (Practical Byzantine Fault Tolerance) can withstand up to (N-1)/3 faulty nodes. In heterogeneous fleet orchestration, BFT becomes relevant when agents operate in zero-trust environments or when a compromised agent could inject falsified telemetry into the Fleet State Estimation system. Requires cryptographic signatures and multiple rounds of voting.

The process by which a distributed system designates a single coordinator node to manage the ordering of operations. In Raft, nodes transition between Follower, Candidate, and Leader states. A Candidate increments its term number and requests votes; it becomes Leader upon receiving a quorum of votes. Leader election is triggered by heartbeat timeout expiration. In fleet orchestration, the elected leader typically owns the Command Queue dispatch and Workflow Engine execution to prevent conflicting task assignments.

The minimum number of nodes that must agree on a decision for it to be committed. In a Raft cluster of 5 nodes, a quorum is 3—ensuring that any two majority groups must overlap by at least one node, preserving consistency across leadership changes. Quorum-based commit prevents split-brain scenarios where two leaders could issue conflicting commands to the fleet. The Distributed Lock primitive relies on quorum consensus to guarantee mutual exclusion across the orchestration middleware.

The mechanism by which a leader propagates committed entries to followers. Each log entry contains a term number, index position, and the command payload. The leader appends entries to its own log, then issues AppendEntries RPCs to followers. An entry is considered committed once replicated to a quorum. In orchestration systems, this log serves as the Event Sourcing backbone—an immutable, replayable history of every task assignment, agent state change, and routing decision.