Zookeeper hard
Which cluster configuration has *worse* availability: A 3-node cluster or a 4-node cluster? (Assuming simple majority quorum)
- A 3-node is worse.
- B 4-node is worse. A 3-node cluster survives 1 failure (needs 2). A 4-node cluster also survives only 1 failure (needs 3). Adding the 4th node increases probability of hardware failure without increasing fault tolerance.
- C They are identical.
- D Even numbers are always better.
Answer: B. 4-node is worse. A 3-node cluster survives 1 failure (needs 2). A 4-node cluster also survives only 1 failure (needs 3). Adding the 4th node increases probability of hardware failure without increasing fault tolerance.
Quorum for 4 is `floor(4/2) + 1 = 3`. If 2 nodes fail, you have 2 left (Minority). Cluster dies. In 3 nodes, Quorum is 2. If 1 fails, you have 2 left. Cluster lives. Both tolerate exactly 1 failure.
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?
- According to the CAP Theorem, how is ZooKeeper classified?
- You need to implement a Distributed Queue where multiple producers push tasks. How does the 'Sequential' Znode flag provide the necessary ordering primitive?