Zookeeper medium
You have a write-heavy cluster and want to scale Read Throughput without increasing the atomic broadcast (ZAB) latency. Why are 'Observer' nodes preferred over additional 'Follower' nodes?
- A Observers perform background data compression on the Znode tree, reducing the memory footprint of the leader node.
- B Observers can accept and commit write operations locally without communicating with the current ensemble leader.
- C Observers serve reads and replicate data but do NOT participate in voting quorums, preventing write throughput degradation as the cluster grows.
- D Observers are automatically promoted to leader state if the majority of followers suffer a simultaneous network partition.
Answer: C. Observers serve reads and replicate data but do NOT participate in voting quorums, preventing write throughput degradation as the cluster grows.
Adding Followers increases the voting pool size. Since writes require a majority vote, more Followers = more votes to collect = slower writes. Observers allow you to scale reads linearly with zero impact on write latency.
One system design question a day, with spaced repetition so the ones you miss come back.
Get the appRelated questions
- What is the primary technical function of a ZooKeeper 'Watch'?
- A system administrator increases `jute.maxbuffer` to 5MB on every ZooKeeper server to store large configuration objects. However, write operations larger than 1MB still fail. What is the most likely cause?
- By default, `forceSync` is enabled. If you disable it, what trade-off are you making?
- If the specific ZooKeeper node a client is connected to crashes, what should the client do?
- Which cluster configuration has *worse* availability: A 3-node cluster or a 4-node cluster? (Assuming simple majority quorum)
- According to the CAP Theorem, how is ZooKeeper classified?