Understanding CAP Theorem, BASE Theory, and Their Implementation with Zookeeper (CP) and Eureka (AP)

The CAP principle, introduced by Eric Brewer in 2000, states that a distributed system can satisfy at most two of the three properties: Consistency, Availability, and Partition tolerance. Consistency means all nodes see the same data after a write; Availability ensures every request receives a response, even if the data is stale; Partition tolerance guarantees the system continues operating despite network partitions.

Because network failures are inevitable, a system must always preserve Partition tolerance and choose between Consistency (CP) or Availability (AP). The article illustrates this with a distributed cache example, showing that guaranteeing consistency requires synchronous writes to all nodes, which sacrifices availability during partitions, while guaranteeing availability allows reads of stale data, sacrificing consistency.

To address the limitations of strict CAP, the BASE model (Basically Available, Soft state, Eventually consistent) offers a pragmatic balance, accepting that strong consistency is costly and instead aiming for eventual consistency where data converges over time.

Implementation of CP with Zookeeper: Zookeeper clusters use a leader‑follower architecture. Roles include Leader (handles all write requests), Follower (handles reads and participates in leader election), and Observer (read‑only, improves read performance). Data synchronization follows a two‑phase commit: the leader logs writes, replicates them to followers, waits for acknowledgments, commits locally, then instructs followers to commit. Leader election and data sync after a failure render the cluster unavailable until a new leader is chosen.

Implementation of AP with Eureka: Eureka clusters consist of identical nodes that can handle both reads and writes. Servers periodically replicate their registries, and clients send heartbeats every 30 seconds. If heartbeats stop, servers may enter a self‑protection mode to avoid premature deregistration. This design favors high availability, accepting eventual consistency of the service registry.

Both implementations illustrate how the choice between CP and AP influences system behavior: Zookeeper ensures strong consistency at the cost of availability during failures, while Eureka prioritizes availability, tolerating temporary inconsistencies.

References: "Comprehensive Interpretation of CAP Theorem" and "ZooKeeper: Distributed Process Coordination".