Zookeeper medium
What is the primary architectural reason that ZooKeeper's total Write Throughput typically decreases as the number of Follower nodes in the ensemble increases?
- A Because the leader must perform a synchronous disk fsync on every single follower before acknowledging the transaction to the client.
- B More nodes increase the networking and coordination overhead required to reach a majority (quorum) consensus for every atomic broadcast.
- C The ZAB protocol uses an exponential backoff strategy for gossip propagation that slows down quadratically with the node count.
- D Adding followers increases the likelihood of hash collisions in the internal Znode metadata storage engine.
Answer: B. More nodes increase the networking and coordination overhead required to reach a majority (quorum) consensus for every atomic broadcast.
ZooKeeper is optimized for reads. It does not scale writes horizontally. If you need high write throughput, ZooKeeper is the wrong tool (use Kafka or Cassandra).
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?