Zookeeper medium
Normally, Sessions are Global (tracked by the Leader). What is the specific architectural benefit of an 'Observer' node managing 'Local Sessions'?
- A It reduces coordination load on the Leader, though ephemeral nodes created by these sessions are not visible to the rest of the cluster.
- B It allows the Observer to perform optimistic concurrency writes without needing follow-up verification from the leader node.
- C It forces the client to use a more secure authenticated handshake that bypasses the standard ZAB protocol.
- D It enables the cluster to survive a total network partition by granting every node local leadership authority.
Answer: A. It reduces coordination load on the Leader, though ephemeral nodes created by these sessions are not visible to the rest of the cluster.
Global sessions require Leader heartbeat tracking (expensive). Local sessions are cheap but limited (cannot own persistent ephemeral nodes). They effectively upgrade to Global only when needed.
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?