Why Eureka Chooses Weak Consistency: AP Model & Peer‑to‑Peer Sync Explained

1. Weak Data Consistency

ZooKeeper provides strong consistency, but Eureka follows a weak consistency model. According to the CAP theorem, a distributed system can satisfy at most two of the three properties: Consistency, Availability, and Partition Tolerance.

Eureka chooses Availability (A) over Consistency (C), ensuring that service consumers can always obtain a service list, even if the data may be stale.

CAP theory states that the three properties cannot be simultaneously satisfied; at most two can be achieved.

2. Eureka’s Data Synchronization Method

2.1 Replication Mode

Eureka uses a peer‑to‑peer (P2P) replication model, where each node can receive write operations and then propagate updates to other peers. This avoids a single master bottleneck but may cause data conflicts during synchronization.

2.2 Synchronization Process

Each Eureka Server also acts as a Eureka Client. After startup, a server requests service information from a peer and copies it locally. When a server’s own data changes (e.g., registration, renewal, cancellation), it notifies other peers to keep data synchronized.

To prevent endless replication loops, Eureka includes a special HTTP header HEADER_REPLICATION in replication requests, allowing peers to recognize and skip further replication of the same change.

Data conflicts are resolved using the lastDirtyTimestamp attribute, which acts like a version number. When two servers exchange data:

If the sender’s data is newer, the receiver returns 404, prompting the sender to re‑register the instance.

If the sender’s data is older, the receiver returns 409, instructing the sender to synchronize with the newer data.

Heartbeats (renewal operations) serve as a final repair mechanism: if a server detects mismatched instance data, it can trigger a re‑registration to correct the inconsistency.

3. Summary

Eureka implements weak data consistency, choosing the AP side of the CAP theorem.

It uses a peer‑to‑peer replication model for data copying.

Conflicts are resolved via the lastDirtyTimestamp attribute.

Heartbeat mechanisms ensure eventual data repair.