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 leaderkey 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)