Consensus protocols buy agreement, not application correctness

Consensus protocols buy agreement, not application correctness. I use Paxos, Raft, or PBFT when a distributed system needs replicas to settle on one ordered history despite failures. That is a consequential guarantee: it prevents healthy replicas from committing incompatible histories under the protocol’s assumptions. It does not tell me whether the chosen command was allowed, whether its data was fresh, or whether executing it preserved the business invariant the application actually exists to protect.

The distinction starts with state-machine replication. Consensus gives each replica the same committed sequence, and deterministic execution should carry those replicas through the same state transitions. Raft makes the mechanism unusually legible through leaders, terms, log matching, leader completeness, and state-machine safety. None of those properties validates the meaning of an entry. A cluster can safely agree to debit the wrong account, accept an obsolete schema, or advance a workflow from an impossible state.

Safety and liveness sharpen this boundary rather than erase it. Safety says the protocol will not produce conflicting committed outcomes. Liveness says progress can eventually resume under the required timing and failure assumptions. FLP explains why deterministic consensus cannot guarantee termination in a fully asynchronous system with even one crash failure, which is why practical protocols lean on timing assumptions and devices such as randomized election timeouts. These are answers to distributed coordination, not proofs of application validity.

Operational refinements stay on the same side of the line. Pre-vote can reduce disruptive term changes when an isolated node rejoins. Joint consensus can move membership between configurations without creating two legitimate quorums. Snapshots can compact a long replicated log while preserving the state needed to continue. These mechanisms protect availability, continuity, and the integrity of replicated history. They cannot decide whether a retried request represents the same intent or a new purchase.

The gap becomes expensive at system boundaries. A committed command may trigger an email, payment, webhook, or job outside the replicated state machine. Agreement on the command does not make that side effect exactly once. If execution fails after the external system accepts the action and before local acknowledgement is recorded, a retry can duplicate it. I still need explicit idempotency, durable execution state, and reconciliation. Consensus can order those records; it cannot make an external effect atomic by declaration.

The same applies to freshness, schemas, authorization, and workflow correctness. Replicas may unanimously accept a write based on stale input. They may consistently deserialize a field whose semantics changed without a safe migration. They may agree on a request issued by a caller who should no longer have permission. They may serialize two individually valid transitions into an invalid business outcome. Agreement turns divergence into a single answer; it does not turn that answer into the right one.

There is one precise concession: when the complete application invariant and every effect are encoded as deterministic transitions inside the replicated state machine, consensus can make correctness of that narrow model durable across replicas. The boundary matters. Most production applications cross databases, queues, payment processors, identity systems, and human workflows, so the model is rarely complete. Byzantine protocols such as PBFT extend agreement to malicious or arbitrary replica behaviour through quorums and view changes; they still do not supply missing business semantics.

I therefore treat consensus as one layer in a correctness argument, never as the argument itself. Leader elections, committed logs, membership changes, snapshots, and Byzantine view changes establish who may decide and which history survives. Application code must separately establish what may be decided, how duplicate intent is recognized, which side effects completed, and whether preconditions remain true. Even advisory locks underline the point: the database exposes coordination, while correctness depends on every participant choosing to honour it.