Zookeeper hard
A client connected to Follower A (ZXID 100) disconnects and immediately attempts to connect to Follower B (ZXID 90). How does ZooKeeper prevent a 'Time Travel' scenario where the client sees old data?
- A The connection is accepted, but the client library automatically buffers reads until Follower B reaches ZXID 100.
- B Follower B rejects the connection because the client's 'last seen' ZXID is more advanced than the server's current state.
- C Follower B initiates an emergency 'ForceSync' with the Leader before acknowledging the client's session handshake.
- D The client's session is invalidated, and all its associated Ephemeral nodes are forcefully purged from the ensemble.
Answer: B. Follower B rejects the connection because the client's 'last seen' ZXID is more advanced than the server's current state.
ZooKeeper guarantees 'Monotonic Reads'. A client cannot go 'backward in time'. If the client has seen the future (ZXID 100), a lagging server (ZXID 90) knows it is unqualified to serve that client and rejects it.
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?