Two Eureka servers are configured as peers. An instance registers against server A, but a client reading server B does not see it. How does replication between Eureka peers actually work, and what would you check?

## The peer model Eureka's clustering is deliberately the least sophisticated thing that could work. There is **no leader, no consensus protocol, and no quorum**. Every server holds a full copy of the registry, accepts writes from any client, and forwards each write to its peers. Two nodes, five nodes, one per availability zone — the topology is a fully connected mesh described by configuration. A Eureka server is itself a Eureka client: it can register with its peers and it fetches their registries. That is what makes bootstrapping work at all. ## What gets replicated, and how The four write operations — **register, renew, cancel, status change** — are each replayed to every configured peer as an HTTP call, batched and issued asynchronously. Two properties follow: **It is best-effort.** The write to the local registry succeeds and the client is told so *before* peers have acknowledged anything. If a peer call fails or times out, there is no rollback and no retry queue that guarantees delivery. The cluster diverges and is expected to reconverge. **It is not transitive.** A replicated request is marked as a replication, and a server applies such a request without re-forwarding it. That prevents an infinite forwarding loop in a mesh, but it also means the originating server is solely responsible for reaching *all* peers. This is not gossip — a peer that server A cannot reach does not learn the change from server C. ## How divergence heals The self-healing mechanism is the heartbeat itself. Renewals are replicated too, so an instance registered only on A produces a stream of replicated renewals arriving at B. When B receives a renewal for an instance it has no lease for, it answers not-found, and that response tells the origin to send a full registration instead. Over a heartbeat interval or two, a missed registration repairs itself. A missed *cancel* is repaired more crudely — by the lease simply expiring on the peer that never heard about it, assuming that peer is not in self-preservation. One consequence worth knowing: each peer stamps leases with **its own** clock and computes **its own** self-preservation threshold from the renewals it personally receives. Peers can therefore hold slightly different views of expiry, and one peer can be suppressing eviction while another is evicting normally. ## What to check when a peer is missing an entry **1. Peer URLs.** Each server must list the *other* servers by an address that resolves to that specific node. The classic misconfiguration is pointing every server at one shared virtual hostname or load-balancer address, so that servers end up replicating to themselves or to an arbitrary node, and registrations land wherever the balancer happened to route. List peers individually. **2. Read caching, not replication.** Before concluding replication failed, remember that a Eureka server serves reads from a cached response that refreshes roughly every 30 seconds. An entry can be perfectly replicated and still be invisible in B's responses for that long. Give it a minute before hunting. **3. Startup sync.** A freshly restarted server first tries to fill its registry from its peers. If that sync comes back empty it deliberately waits before serving traffic, so that it does not answer with a nearly empty registry and, worse, start evicting things it never learned about. A server queried during that window looks broken and is not. **4. Connectivity in both directions.** Because replication is per-origin, a one-way network problem produces exactly this asymmetry: registrations made against A appear on B, but registrations made against B never reach A. Test both directions rather than assuming a symmetric failure. **5. Which server did the client actually use?** Clients are configured with a list of server URLs and use one of them. "The instance is missing" is often "the instance registered against the peer the caller does not read from, and has not converged yet". ## The honest summary Eureka's replication buys availability — any server can accept any write while any other is unreachable — at the cost of any consistency guarantee at all. It is the correct trade for a registry whose consumers already cache stale data and already have to survive a wrong address. It would be the wrong trade for a store of record, which is exactly why registries built on a consensus protocol behave so differently under the same partition.