Understanding the Eureka Service Heartbeat Mechanism in Microservices

The article introduces the concept of a heartbeat mechanism in microservices by comparing it to the tribute system of the Tang dynasty, then focuses on Eureka’s service renewal feature as a concrete example.

Who sends the heartbeat? Each registered microservice (e.g., order, product, coupon services) sends its own heartbeat request to the Eureka server.

How often is it sent? When the DiscoveryClient starts, it creates a thread pool heartbeatExecutor that schedules a HeartbeatThread . After an initial 30‑second delay, the thread sends a heartbeat every 30 seconds. The thread‑pool parameters such as maximumPoolSize , corePoolSize , keepAliveTime , and runnableTaskQueue are shown.

How is the heartbeat request sent? The HeartbeatThread runs the renew() method, which ultimately calls:

eurekaTransport.registrationClient.sendHeartBeat(
    instanceInfo.getAppName(),
    instanceInfo.getId(),
    instanceInfo,
    null);

The request URL looks like http://localhost:8080/v2/apps/order/i-000000-1 and it is a PUT request.

How does the server receive the request? The server-side controller ApplicationsResource forwards the request to InstanceResource.renewLease() , which updates the instance’s lastUpdateTimestamp .

What happens after reception? The server updates the lastUpdateTimestamp field of the instance’s Lease object stored in a concurrent hash map. This timestamp is used by a periodic task to detect expired instances and trigger service deregistration.

The article concludes that the heartbeat mechanism, like ancient tribute, lets the central registry know that a service is still alive, and hints at the next topic: service down‑line handling.