30-Second Glance
- A coordination service is a thin reliable KV store over consensus (Raft / Zab) for the small config you cannot get wrong: server/DB IPs, replication schema, leader identity, partition maps.
- ZooKeeper's Zab totally orders every update, so an acked write is visible to all clients in the same order.
- Reads: always-from-leader is linearizable but slow; quorum reads are faster but can miss a just-committed write, so ZooKeeper's sync forces the follower to catch up to the leader first.
- Even with sync there is a lag window — a later leader write can land right after your sync, so design for "never go backward," not "always newest."
- Verdict of the note: too slow for application data, exactly right for backend configuration.
Introduction
Coordination services are just thin layer that're built on distributed consensus algorithm like Raft (The Raft Consensus Algorithm - Leader Election). Basically can help us with all that configuration that we might need within our distributed backend. What types of configurations? IPs for servers and DBs, replication schema (what db is sending writes to which, who's the leader, where are those DBs located, etc) & partitioning breakdown. Can't mess this up!
ZooKeeper achieves strong consistency through a consensus algorithm called Zab (ZooKeeper Atomic Broadcast). Zab ensures that all updates to the ZooKeeper state are totally ordered, meaning that once a write has been acknowledged, it is guaranteed to be visible to all clients in the same order. This is crucial for maintaining consistency across all nodes in the ZooKeeper ensemble.
Recall: Consensus is sloww, but sometimes we need it! For example the above configurations.
A coordination service is a key-value store that allows us to store this data in a reliable way. example: Zookeeper, etcd
How reads work?
Built on top of distributed consensus layer like Raft.
- Can always read from leader (slow).
- If you want to read from multiple nodes, SYNC will keep reads linearizable (only needs to be done once, greater read throughput as a result).
Linearizable Reads and the sync Keyword:
In ZooKeeper, the sync keyword is used to ensure linearizable reads, meaning that a read operation reflects the most recent write operation that was acknowledged by the leader.
However, the concern you’ve raised about the sync keyword and quorum reads highlights an important nuance in distributed systems:
- Quorum Reads: In a system like ZooKeeper, a read operation can be performed by contacting a majority (quorum) of the nodes. This can provide faster reads but doesn’t guarantee that the read is from the most up-to-date node, as the leader may have committed a write that has not yet been propagated to the followers.
- Using sync: The sync operation forces the follower to update itself by contacting the leader before proceeding with the read. This ensures that the read reflects the latest committed state. However, this doesn’t guarantee that the follower will stay up-to-date, as another write could be committed to the leader after the sync operation. If multiple users are writing to the leader, it’s possible that the follower may not immediately reflect subsequent writes.
The Role of Consensus
ZooKeeper’s consensus algorithm ensures that once a write is committed by the leader, it will eventually be propagated to all followers. However, there is always a brief window where a follower may lag behind. This is why ZooKeeper provides the sync operation—to mitigate this lag for read operations, ensuring that they reflect the most recent committed write.
So, while ZooKeeper does provide strong consistency, it’s essential to understand the nuances of how reads and writes are handled in a distributed environment. The trade-off between performance and consistency is a key consideration in designing systems that use ZooKeeper.
If you’re asking whether ZooKeeper provides strong consistency using consensus algorithms, the answer is yes, through the Zab protocol. However, the behavior of reads and the need for synchronization operations like sync are part of the design choices to manage the balance between consistency, availability, and performance.
Conclusion:
Too slow to be used for application data, only key pieces of configuration for your back-end needs to be correct. Built on top of consensus algorithms to maintain linearizability. It's OKAY if reads are little bit out-dated but we'd never jump backwards in Time to some previous state and think that it is more up-to-date than our current state.
Trade-offs
| Approach | Pros | Cons | Use when |
|---|---|---|---|
| Read from leader | Linearizable | Slow; leader-loaded | Config reads that must be current |
| Quorum read without sync | Fast, spread load | Can miss the latest commit | Tolerant config polling |
| Follower read after sync | Linearizable at read time with better sustained read throughput | One sync round-trip; still racy against immediately-later writes | Standard ZooKeeper linearizable reads |
| Stuffing app data in the coordinator | Reuses strong consistency | Latency and throughput collapse | Never — keep it to keys/config only |
Interview One-Liners
Q: What belongs in a coordination service? A: Small critical backend config — IPs, replication topology, leader pointers, partition maps — not application data.
Q: What consensus sits underneath, per the note? A: Raft-style consensus generally; Zab (ZooKeeper Atomic Broadcast) specifically for ZooKeeper, giving totally ordered updates.
Q: Why is leader-only reading slow but safe? A: The leader holds the committed order, so reads are linearizable — at the price of a bottleneck round-trip.
Q: What does ZooKeeper's sync do? A: Forces the follower you are about to read from to catch up with the leader first, making that read linearizable (and amortizing later reads).
Q: Does sync guarantee you stay current? A: No — a new leader write can commit immediately after your sync, so a follower can lag again; the guarantee is no backward jumps, not perpetual freshness.
Q: Examples of production coordinators? A: ZooKeeper and etcd.