# CAP Theorem Explained for Java Distributed Systems: AP vs CP Trade-offs with Code Examples > Understand CAP theorem for Java distributed systems. Explore AP vs CP trade-offs, from Zookeeper to Eureka, with practical code examples. Choose consistency or availability for your architecture. - Repository: [Doocs/advanced-java](https://github.com/doocs/advanced-java) - Tags: deep-dive - Published: 2026-02-28 --- **The CAP theorem states that a distributed Java system can guarantee only two of three properties—Consistency, Availability, or Partition tolerance—at any given time, forcing architects to choose between CP systems like Zookeeper for strong consistency or AP systems like Eureka for high availability.** The CAP theorem, also known as Brewer’s theorem, is a foundational concept for building resilient Java microservices. According to the `doocs/advanced-java` repository, understanding whether to prioritize consistency or availability determines your choice between coordination services like Zookeeper and service discovery tools like Eureka. ## What Is the CAP Theorem? The CAP theorem defines three core properties that distributed systems must balance: ### Consistency (C) Every read returns the most recent write. In Java systems, this often requires strong coordination protocols such as Zookeeper’s leader election to ensure all nodes see the same state before acknowledging a request. ### Availability (A) Every request receives a response, regardless of the current state of the system. This is typically achieved by allowing reads and writes to continue even when some replicas are out-of-sync, such as Eureka’s client-side caching mechanism. ### Partition Tolerance (P) The system continues to operate despite network partitions. When a partition occurs, the system must choose between **C** and **A**. The "P" itself is not a design choice—it is a reality of any real-world network. ## Why Partition Tolerance Is Non-Negotiable When a network partition appears, nodes on opposite sides cannot communicate. The system must decide whether to **block** operations to preserve consistency (CP) or to **serve** possibly stale data to stay available (AP). As documented in [`docs/distributed-system/distributed-system-cap.md`](https://github.com/doocs/advanced-java/blob/main/docs/distributed-system/distributed-system-cap.md), partition tolerance is inevitable in distributed Java applications because network failures are unavoidable in production environments. ## CAP Trade-offs in the Java Ecosystem Java developers typically choose between AP and CP architectures based on business requirements: ### Eureka (AP) – High Availability Service Discovery Eureka guarantees high availability; clients cache the last known registry and serve requests even when the registry is temporarily unreachable. This makes it ideal for service discovery where stale data is acceptable. **Reference:** Detailed Eureka usage is documented in [`docs/micro-services/how-eureka-enable-service-discovery-and-service-registration.md`](https://github.com/doocs/advanced-java/blob/main/docs/micro-services/how-eureka-enable-service-discovery-and-service-registration.md). ### Zookeeper (CP) – Strong Consistency Coordination Zookeeper provides strong consistency via quorum-based writes. A leader must be elected before serving updates, sacrificing availability during leader loss. This is critical for configuration management and leader election. **Reference:** The CP behavior is explained in [`docs/distributed-system/distributed-system-cap.md`](https://github.com/doocs/advanced-java/blob/main/docs/distributed-system/distributed-system-cap.md) under the Zookeeper section. ### Consul (CP) – Consistent Service Mesh Consul uses majority voting for service registration and health checks, yielding consistency over availability. Like Zookeeper, it prioritizes data accuracy over uptime during network partitions. ## Practical Java Implementations ### Implementing AP with Eureka Client To build an available service discovery system with Eureka, add the Spring Cloud dependency and enable client-side registration: ```xml org.springframework.cloud spring-cloud-starter-netflix-eureka-client ``` ```java // Application.java – enable Eureka client @SpringBootApplication @EnableEurekaClient // <-- registers the service with Eureka public class Application { public static void main(String[] args) { SpringApplication.run(Application.class, args); } } ``` ```java // Sample REST controller that discovers another service via Eureka @RestController @RequestMapping("/order") public class OrderController { @Autowired private RestTemplate restTemplate; // configured with @LoadBalanced @GetMapping("/{id}") public Order getOrder(@PathVariable String id) { // The logical service name "inventory-service" is resolved by Eureka String url = "http://inventory-service/inventory/" + id; return restTemplate.getForObject(url, Order.class); } } ``` *Why it’s AP:* If the Eureka server becomes temporarily unavailable, the client continues to serve requests using the **last cached registry**. ### Implementing CP with Zookeeper and Curator For scenarios requiring strict consistency, use Zookeeper with the Curator framework: ```xml org.apache.curator curator-framework 5.5.0 ``` ```java // ZkLeaderElection.java – simple CP leader election public class ZkLeaderElection { private static final String LEADER_PATH = "/app/leader"; private CuratorFramework client; public ZkLeaderElection(String zkConnectString) { client = CuratorFrameworkFactory.builder() .connectString(zkConnectString) .retryPolicy(new ExponentialBackoffRetry(1000, 3)) .build(); client.start(); } public void elect() throws Exception { // Attempt to create an EPHEMERAL node – only one client will succeed try { client.create() .creatingParentContainersIfNeeded() .withMode(CreateMode.EPHEMERAL) .forPath(LEADER_PATH, "my-instance".getBytes()); System.out.println("I am the leader!"); } catch (NodeExistsException e) { System.out.println("Another instance is leader."); } } public void close() { client.close(); } } ``` *Why it’s CP:* Zookeeper requires a **majority quorum** for writes; if the quorum is not reachable, the operation blocks, preserving consistency at the cost of availability. ### Handling Network Partitions with Fallback Caching A robust Java service should detect partitions and gracefully degrade: ```java @Service public class ProductService { private final RestTemplate restTemplate; private final Cache localCache = Caffeine.newBuilder() .expireAfterWrite(5, TimeUnit.MINUTES) .build(); public Product getProduct(String id) { try { // Remote call – may fail during a partition Product p = restTemplate.getForObject( "http://product-service/product/" + id, Product.class); localCache.put(id, p); // refresh cache on success return p; } catch (ResourceAccessException e) { // Partition detected – fall back to stale cache (AP style) Product cached = localCache.getIfPresent(id); if (cached != null) { return cached; // serve stale data } throw new IllegalStateException("Unable to fetch product and no cache"); } } } ``` *Pattern:* The code prefers the latest data (C) but safely degrades to a cached version (A) when a partition prevents remote calls, illustrating a **hybrid** approach often used in real systems. ## Key Source Files in doocs/advanced-java | File | Why it’s important | |------|-------------------| | [`docs/distributed-system/distributed-system-cap.md`](https://github.com/doocs/advanced-java/blob/main/docs/distributed-system/distributed-system-cap.md) | Core explanation of the CAP theorem, the meaning of **P**, and a comparison table of AP/CP frameworks | | [`docs/micro-services/micro-services-technology-stack.md`](https://github.com/doocs/advanced-java/blob/main/docs/micro-services/micro-services-technology-stack.md) | Shows the technology stack, including **Eureka** (AP) and **Zookeeper** (CP) with a concise comparison | | [`docs/micro-services/how-eureka-enable-service-discovery-and-service-registration.md`](https://github.com/doocs/advanced-java/blob/main/docs/micro-services/how-eureka-enable-service-discovery-and-service-registration.md) | Detailed walkthrough of Eureka registration, heart-beat, and fail-over mechanisms—useful for AP-style service discovery | | [`docs/distributed-system/distributed-system-interview.md`](https://github.com/doocs/advanced-java/blob/main/docs/distributed-system/distributed-system-interview.md) | Lists interview-style questions about CAP, partitions, and trade-offs, helping readers think about real-world scenarios | These files together give a complete picture of **how the CAP theorem is interpreted, taught, and applied within the Java ecosystem** in this repository. ## Summary - The **CAP theorem** forces Java architects to choose between **Consistency** and **Availability** when network partitions occur, as **Partition tolerance** is mandatory in real-world distributed systems. - **AP systems** like **Eureka** prioritize availability by allowing clients to operate on cached registry data during network failures, making them ideal for service discovery. - **CP systems** like **Zookeeper** and **Consul** enforce strict consistency through quorum-based writes, sacrificing availability during leader elections or network splits. - Production Java services should implement **graceful degradation** patterns, such as client-side caching with **Caffeine**, to handle partitions without hard failures. ## Frequently Asked Questions ### What happens if a Java system tries to guarantee all three CAP properties simultaneously? Attempting to guarantee all three properties simultaneously is impossible according to the CAP theorem. If a network partition occurs, the system must choose between consistency (blocking operations until the partition heals) or availability (returning potentially stale data). In the `doocs/advanced-java` documentation, this is emphasized as a fundamental constraint of distributed computing, not a technical limitation that can be engineered away. ### Is Eureka always the right choice for service discovery in Spring Boot applications? Eureka is the right choice when your architecture prioritizes **availability over strict consistency**. As documented in [`docs/micro-services/how-eureka-enable-service-discovery-and-service-registration.md`](https://github.com/doocs/advanced-java/blob/main/docs/micro-services/how-eureka-enable-service-discovery-and-service-registration.md), Eureka clients cache the registry locally and continue operating even when the Eureka server is unreachable. However, if your use case requires immediate consistency across all nodes—such as configuration management or leader election—Zookeeper or Consul would be more appropriate despite their reduced availability during partitions. ### How does Zookeeper ensure consistency during a network partition? Zookeeper ensures consistency through a **quorum-based consensus protocol**. As implemented in the repository's examples, Zookeeper requires a majority of nodes (quorum) to acknowledge a write before it is considered committed. During a network partition, if the leader cannot reach a quorum, write operations block until the partition heals, ensuring that all remaining nodes maintain a consistent state. This CP behavior is demonstrated in the leader election code using Curator's `CreateMode.EPHEMERAL` nodes. ### Can a Java microservice be both AP and CP at different times? Yes, modern Java microservices often implement **adaptive or hybrid CAP strategies** depending on the operation type. For example, a service might use **CP** behavior for critical financial transactions requiring strong consistency (using Zookeeper or distributed transactions), while employing **AP** behavior for read-heavy catalog queries (using Eureka with client-side caching). The repository's fallback caching example demonstrates this hybrid approach, where the system attempts strong consistency first but degrades to available cached data when partitions occur.