Leader Election

• Imagine a situation where we might want our database to connect to a third party service (stripe, plaid, youtube, Google Analytics, etc.)

• That would look like this:

<!-- -->

Third Party Service             Database
[                 ]<-------->[   Master   ]

• This isn’t ideal: so we’ll put our own service which gates out certain functionality.

<!-- -->

Third Party Service           Your Service           Database
[                 ]<-------->[   Leader   ]<------->[        ]

• But here, we only have server that is a single point of failure.
• Let’s make it more redundant by adding more servers.

<!-- -->

Third Party Service           Your Service           Database
[                 ]<-------->[   Leader   ]<------->[        ]
[                 ]<-------->[   Leader   ]<------->[        ]
[                 ]<-------->[   Leader   ]<------->[        ]
[                 ]<-------->[   Leader   ]<------->[        ]
[                 ]<-------->[   Leader   ]<------->[        ]

• But now, we want every operation to only occur once.

• We can’t charge a person twice for the same invoice.

• Leader Election has a server elect one of the servers as a leader, which is the only server that connects to the database.

<!-- -->

Third Party Service           Your Service           Database
[                 ]<-------->[   Leader   ]<------->[        ]
[                 ]--------->[  Follower  ]<------->[        ]
[                 ]--------->[  Follower  ]<------->[        ]
[                 ]--------->[  Follower  ]<------->[        ]

• Now, all writes to the leader have to propagate to the followers in case of failure, and when the leader dies, then the followers have to relect a new leader.

• Consensus building (Leader Election) is actually quite hard.

• It’s hard to share some state.

• We need a Consensus Algorithm to achieve this leader election.

Consensus Algorithms

• Paxos

• Raft

• Two tools that implement Leader Election:

  • Zookeeper
  • Etcd

• Etcd is a key-value store that is highly available and strongly consistent.

  • Etcd uses Raft for leader election

• Have Etcd use a key value that has a leader key set to a value of the leader server.

• Then, all the servers are strongly consistent and synced to a leader.

Prev: [replication-and-sharding](replication-and-sharding.md) Next: [peer-to-peer-networks](peer-to-peer-networks.md)