It's not agreeing on a transaction that's often the most expensive consensus operation in a distributed system, it's agreeing on who gets to decide. The latency incurred during leader election directly dictates your system's Mean Time To Recovery (MTTR) for critical control plane operations, often measured in hundreds of milliseconds of complete unavailability.
Imagine a payment processing service where a single "controller" node is responsible for assigning transaction IDs and routing requests to different payment gateways. If this controller node suddenly crashes, your entire payment service grinds to a halt. While the data nodes might still hold consistent state, without a controller, new transactions cannot be initiated or routed. Users stare at loading spinners, merchants lose sales, and your service effectively becomes unavailable. This isn't about data replication lagging or transaction conflicts; it's a complete stop of operational flow because the system can't agree on who is in charge to make fundamental routing decisions.
Core Concept: Leader Election via Consensus
Distributed consensus algorithms like Paxos or Raft are primarily known for ensuring that all nodes in a distributed system agree on a single value, even amidst failures. While this is crucial for data consistency, a common and critical application is agreeing on a leader node. This leader is often responsible for coordinating other nodes, managing metadata, or being the sole write-endpoint to simplify consistency models.
