Understanding the LCR Algorithm for Distributed Leader Election

Arpit Bhayani

Arpit Bhayani

Aug 22, 2022 • 6 min read

Play

Understanding the LCR Algorithm for Distributed Leader Election

Leader election is a fundamental coordination problem in distributed systems. When a primary or leader node crashes, the cluster must automatically elect a replacement without requiring manual human intervention. Without automated failover and leader election, systems face prolonged downtime and lose their self-healing properties.

Among the various distributed consensus and election techniques, the LCR algorithm (named after Le Lann, Chang, and Roberts) represents one of the simplest, most intuitive, and most elegant foundational algorithms for ring topologies.


1. Prerequisites and Core Assumptions

The LCR algorithm operates under minimal assumptions, which makes it particularly attractive when topological knowledge is scarce.

Topology: The Unidirectional Ring

  • Nodes are organized logically in a unidirectional ring.
  • A node only needs to know the network identity of its immediate clockwise neighbor.
  • Nodes do not need global knowledge of the network; a node does not need to know the total number of nodes (nn) in the system.
graph LR
    A((Node 3)) --> B((Node 9))
    B --> C((Node 1))
    C --> D((Node 18))
    D --> A

Synchronous Execution Model

  • The algorithm runs in a synchronous mode.
  • When an election is triggered (e.g., upon detecting that the current leader has failed), nodes advance through synchronous rounds where message passing and processing occur in coordinated steps.

Identifiers (UIDs)

  1. Uniqueness: Every node possesses a globally unique identifier (UID). These can be integers, fixed-size bitstrings, or MAC/IP combinations.
  2. Total Ordering: UIDs must be strictly comparable (i.e., for any two UIDs AA and BB, either A>BA > B or B>AB > A).

The goal of the algorithm is to elect the node with the highest UID as the new leader.


2. How the LCR Algorithm Works

When a failure is detected, every operational node nominates itself by sending its own UID to its clockwise neighbor.

Message Forwarding Logic

When a node with identifier UIDownUID_{own} receives a message containing UIDincomingUID_{incoming} from its counter-clockwise neighbor, it evaluates three mutually exclusive conditions:

  1. UIDincoming>UIDownUID_{incoming} > UID_{own}:

    • The incoming candidate has a higher priority than the local node.
    • The local node realizes it cannot become the leader and forwards UIDincomingUID_{incoming} to its clockwise neighbor.
  2. UIDincoming<UIDownUID_{incoming} < UID_{own}:

    • The incoming candidate has a lower priority than the local node.
    • The local node discards (swallows) the message. The smaller UID is dropped and travels no further.
  3. UIDincoming==UIDownUID_{incoming} == UID_{own}:

    • The node has received its own message back.
    • Because every node on the ring only forwards UIDs strictly greater than their own, receiving one’s own UID guarantees that it survived a full cycle around the ring without being dropped by any larger node.
    • The node declares itself the elected leader.
Incoming Message (UID_incoming)


    ┌──────────────┐       UID_in < UID_own
    │ Compare with │ ─────────────────────────► [Discard Message]
    │   UID_own    │
    └──────────────┘
      │          │
      │ UID_in   │ UID_in == UID_own
      │ >        ▼
      │ UID_own  [Declare Self as Leader]
      ▼          [Initiate Halt / Announcement]
[Forward UID_in to Clockwise Neighbor]

3. Algorithm Walkthrough by Example

Consider four nodes arranged in a clockwise ring:

Node 3Node 9Node 1Node 18Node 3\text{Node } 3 \rightarrow \text{Node } 9 \rightarrow \text{Node } 1 \rightarrow \text{Node } 18 \rightarrow \text{Node } 3

  1. Round 1:

    • Node 3 sends 3 to Node 9.
    • Node 9 sends 9 to Node 1.
    • Node 1 sends 1 to Node 18.
    • Node 18 sends 18 to Node 3.
  2. Round 2 (Evaluation & Forwarding):

    • Node 9 receives 3: Since 3<93 < 9, Node 9 drops the message.
    • Node 1 receives 9: Since 9>19 > 1, Node 1 forwards 9 to Node 18.
    • Node 18 receives 1: Since 1<181 < 18, Node 18 drops the message.
    • Node 3 receives 18: Since 18>318 > 3, Node 3 forwards 18 to Node 9.
  3. Round 3:

    • Node 18 receives 9: Since 9<189 < 18, Node 18 drops the message.
    • Node 9 receives 18: Since 18>918 > 9, Node 9 forwards 18 to Node 1.
  4. Round 4 & 5:

    • Node 1 receives 18: Since 18>118 > 1, Node 1 forwards 18 to Node 18.
    • Node 18 receives 18: Node 18 sees UIDincoming==UIDownUID_{incoming} == UID_{own}.
    • Result: Node 18 is elected as the leader.

4. Halting and Termination

In a distributed network where nodes do not know the total node count nn, nodes cannot rely on a fixed counter or loop to terminate the election.

  1. Leader Detection: Only the winning candidate recognizes termination, which occurs the instant its own UID traverses the entire ring.
  2. Announcement Phase: The newly elected leader constructs an announcement / halt message containing its UID and dispatches it clockwise.
  3. Local State Update: Each downstream node that receives the announcement:
    • Records the new leader’s identity locally.
    • Ceases all election-related processing.
    • Forwards the announcement message clockwise to the next neighbor.
  4. Cycle Complete: When the announcement message reaches the leader again, the message is dropped, and the entire ring is synchronized in the elected state.

5. Complexity Analysis

In distributed algorithms, efficiency is evaluated primarily using communication complexity (the total number of network messages exchanged).

MetricComplexity
Time Complexity (Rounds)O(n)O(n)
Worst-Case Message ComplexityO(n2)O(n^2)
Best-Case Message ComplexityO(n)O(n)

Worst-Case Scenario: O(n2)O(n^2)

  • Occurs when nodes are ordered in strictly descending order along the clockwise direction (e.g., N,N1,N2,,1N, N-1, N-2, \dots, 1).
  • The node with identifier ii traverses ii hops before being swallowed by a larger node.
  • Total messages exchanged:

i=1ni=n(n+1)2=O(n2)\sum_{i=1}^{n} i = \frac{n(n+1)}{2} = O(n^2)

Best-Case Scenario: O(n)O(n)

  • Occurs when nodes are ordered in ascending order clockwise (e.g., 1,2,3,,N1, 2, 3, \dots, N).
  • Messages with smaller UIDs are swallowed after just one hop by their immediate successor.
  • Only the message with the highest UID completes the full traversal of nn hops.

Why Communication Complexity Matters

At scale, an O(n2)O(n^2) message footprint can saturate network interfaces and cause congestion at the network layer. Consequently, while LCR is ideal for smaller topologies or embedded systems due to its simplicity, large distributed clusters typically favor algorithms with sub-quadratic message complexity (such as the Hirschberg-Sinclair algorithm, which achieves O(nlogn)O(n \log n)).


6. Summary and Key Takeaways

  • Minimal State: The LCR algorithm requires no global cluster size knowledge; nodes only need to be aware of their immediate clockwise neighbor.
  • Filter-by-Comparison: Larger UIDs traverse the ring, while smaller UIDs are dropped immediately upon encountering a higher-priority node.
  • Natural Leader Discovery: The maximum UID is the only candidate guaranteed to traverse all nn nodes and return to its origin.
  • Two-Phase Completion: Election is followed by an explicit announcement pass to update node state and gracefully halt execution across the ring.
  • Trade-off: LCR prioritizes algorithmic simplicity and low memory overhead over worst-case communication efficiency (O(n2)O(n^2) messages).
Arpit Bhayani

Principal Engineer II at Razorpay - building Agent Studio, Ex-staff engg at GCP Memorystore & Dataproc, Creator of DiceDB, ex-Amazon Fast Data, ex-Director of Engg. SRE and Data Engineering at Unacademy. I spark engineering curiosity through my no-fluff engineering videos on YouTube and my courses