Tiffin runs a dispatcher for each city. It looks at ready orders and free riders and makes assignments. You run three copies of the Bengaluru dispatcher so one crash doesn't stop deliveries. But only one of them may assign at a time, or two riders turn up for the same order.
So the three copies need to agree on who's in charge, notice quickly when that one dies, and never, even during a network split, both believe they're in charge. Module 13 showed why this is hard, and Module 19 walked through Raft, the algorithm that solves it. You almost never implement Raft yourself. You use a coordination service that already does: etcd or Apache ZooKeeper.
What they're for
A coordination service is a small, very reliable store for the facts that the rest of your system must agree on.
A coordination service is a tiny, strongly consistent database for decisions, not for data.
Typical uses:
- Leader election: which dispatcher is active for Bengaluru.
- Distributed locks and leases: who may run the nightly payout job.
- Service discovery and membership: which kitchen-gateway servers are alive right now.
- Configuration: feature flags and settings that every server must see the same way, with instant change notifications.
You've used one even if you didn't know it. Kubernetes stores all cluster state in etcd. Older Kafka, Hadoop and HBase clusters use ZooKeeper. (Kafka has since replaced ZooKeeper with its own built-in Raft, called KRaft, and Kafka 4.0 in 2025 dropped ZooKeeper support entirely.)