ZooKeeper Interview Questions and Core Concepts

ZooKeeper is an open‑source distributed coordination service that manages cluster state, offering simple interfaces, high performance, and stable functionality for tasks such as data publishing/subscription, load balancing, naming services, distributed locks, and queue management.

It guarantees several consistency properties: sequential consistency, atomicity, a single view, reliability, and eventual (real‑time) consistency.

The ZAB (ZooKeeper Atomic Broadcast) protocol provides crash recovery and message broadcasting. It operates in two modes: crash‑recovery and normal message broadcast, handling leader election, proposal voting, and transaction commitment.

ZooKeeper’s hierarchical namespace consists of znodes, each limited to 1 MiB of data. Four znode types exist: PERSISTENT , EPHEMERAL , PERSISTENT_SEQUENTIAL , and EPHEMERAL_SEQUENTIAL .

Watchers allow clients to register for notifications on specific znodes. When an event occurs, the server sends a one‑time notification; the watcher is then removed to reduce load. The workflow includes client registration, server storage, event triggering, and client callback.

Access control is managed via ACLs with schemes such as IP, DIGEST, WORLD, and SUPER, defining permissions like CREATE, DELETE, READ, WRITE, and ADMIN.

Since version 3.2.0, the chroot feature lets each client operate within its own namespace, providing isolation for multiple applications sharing a cluster.

Session management uses a bucketed strategy where each session’s expiration time is calculated as:

ExpirationTime_ = currentTime + sessionTimeout

ExpirationTime = (ExpirationTime_ / ExpirationInterval + 1) * ExpirationInterval

Server roles include Leader (handles all transaction ordering), Follower (processes client reads and forwards writes), and Observer (adds read capacity without voting). Servers transition among LOOKING, FOLLOWING, LEADING, and OBSERVING states.

Data synchronization after leader election follows four patterns: DIFF, TRUNC+DIFF, TRUNC, and SNAP, based on the learner’s last processed zxid relative to the leader’s committed log range.

ZooKeeper ensures transaction order using a globally increasing zxid (epoch + counter). The system tolerates node failures as long as a majority of servers remain operational; a 3‑node cluster can lose one node, while a 2‑node cluster cannot lose any.

Load balancing in ZooKeeper is configurable, whereas Nginx provides static weight‑based balancing with higher throughput.

Deployment modes are standalone, pseudo‑cluster, and full cluster, requiring at least 2N+1 servers (e.g., three for N=1). Dynamic scaling is possible via full or rolling restarts, with full support introduced in version 3.5.

Watchers are one‑time triggers to avoid excessive network traffic; they must be re‑registered after each event.

Java clients include the native ZooKeeper client (zkclient) and Apache Curator.

Google’s Chubby implements Paxos and is not open source; ZooKeeper is its open‑source counterpart using the ZAB protocol, a Paxos variant.

Typical ZooKeeper use cases encompass configuration management, service discovery, distributed coordination/notification, cluster management, master election, distributed locks, and queues.