Service Discovery Interview: Should You Choose CP or AP? Why?

In cloud‑native and microservice environments, service instances are dynamically deployed and their IP addresses and ports change frequently, making it impossible for clients to know the exact location of a service. To ensure that a client can always find the correct server, a service‑discovery mechanism is introduced.

Why service discovery is needed

Service addresses are not fixed; they may change on each startup.

Services can scale up/down, restart, or be upgraded, causing frequent address changes.

The discovery process typically includes:

Service registration – each service reports its network address to a registration center.

Periodic heartbeat – services send heartbeats to indicate they are alive.

Service deregistration – when a service stops, the center removes it.

Client query – callers fetch the list of available addresses from the center.

Load balancing – the client selects an instance from the list.

CAP theorem recap

CAP (Consistency, Availability, Partition tolerance) states that a distributed system cannot simultaneously guarantee all three properties. Eric Brewer proposed the conjecture in 1998; Gilbert and Lynch proved it in 2002.

C – all nodes see the same data.

A – every request receives a response.

P – the system continues to operate despite network partitions.

Only two of the three can be achieved at the same time.

CAP combinations

CA (ignore P) – unrealistic because networks always experience partitions.

CP (ignore A) – favors strong consistency; used in banking or databases.

AP (ignore C) – favors availability; common in social platforms and ticketing systems.

ZooKeeper‑based service discovery (CP)

ZooKeeper stores service metadata in a znode hierarchy, e.g., /dubbo/com.foo.BarService with providers and consumers sub‑nodes. Providers create temporary nodes under providers so that a crash automatically removes the node. Consumers create temporary nodes under consumers and watch the providers directory for changes. When a provider goes online or offline, ZooKeeper notifies all watchers.

Problems:

Strong consistency forces every write to be replicated to all ZooKeeper nodes, leading to high CPU usage and possible crashes under heavy load.

During a network partition, a minority of ZooKeeper nodes cannot serve discovery requests, breaking the service.

Eureka‑based service discovery (AP)

Eureka‑Client registers itself with an Eureka‑Server and sends a heartbeat every 30 seconds. The server synchronizes registration and heartbeat information to other Eureka servers to keep data consistent. Clients pull the full list of instances from the server.

Problems:

Clients receive all service addresses, even those they do not need, wasting memory.

Clients poll the server periodically, causing stale data and unnecessary traffic.

Each Eureka node stores the entire dataset, leading to memory pressure and limited scalability.

Nacos – hybrid AP/CP

Nacos can operate in AP mode (default) using the Distro protocol when a client registers with ephemeral=true, or switch to CP mode with Raft when ephemeral=false. This allows both consistency‑focused and availability‑focused services to coexist in the same cluster.

Improvements over Eureka include batch data synchronization, on‑demand push (actually client‑pull every 30 seconds), and a dual‑cluster architecture separating session handling from data aggregation, which reduces memory usage and improves scalability.

Interview takeaway

In service‑discovery scenarios, availability (A) is usually more important than strict consistency (C) because having some information—even if slightly stale—is better than having none. Therefore, interviewers often expect the AP choice, with the caveat that retry mechanisms and load balancing mitigate occasional stale or wrong addresses.