Skip to content
Software Architecture Guide

Ping/Echo

Explanation

Section titled “Explanation”

Ping/echo is a way to detect faults. It is one of the fault detection tactics described in Fault Detection Tactic. One component sends a request to another. The receiver sends an echo back. The two messages form an asynchronous request/response pair (see Synchronous vs. Asynchronous Communication).

What the echo tells you. The echo shows that the target is alive and responding. It also shows whether the network path works and how long the round trip takes.

The time threshold. The sender must know how long to wait for the echo. When that time runs out with no reply, the sender declares a failure. Teams must set timeouts and failure thresholds so that short problems, such as a network delay, do not trigger needless action. Such wrong alarms are called false positives.

Matching replies. In the standard echo defined in RFC 792, the receiver returns the data from the request. It also returns an identifier and a sequence number. The sender uses these to match each reply to its request.

Ping/echo versus heartbeat. Heartbeat is a periodic exchange between a system monitor and the monitored process. The key difference is who starts the check. A monitor, in general, watches key components for malfunctions or network congestion.

Shallow checks. A simple ping shows only that the process can respond. It does not test the services the component depends on. A process that responds is not necessarily ready to serve.

In practice. Health endpoint monitoring uses external tools that probe an application at regular intervals. Load balancers and traffic routers use the results to send requests to healthy instances (see Load Balancer). Kubernetes liveness probes lead the kubelet to restart a container that fails more often than allowed. Readiness probes decide whether a Pod receives traffic.

Example

Section titled “Example”

A monitoring tool sends a small request to an order service. The service answers. The tool records the reply and moves on. Later the service stops answering. The tool waits for the configured time, then declares the service failed. A load balancer stops sending customers to that instance.

Trade-offs

Section titled “Trade-offs”
  • Probe cost. Probes add traffic. At high frequency across many instances, the overhead can measurably slow the application. Balance the probe interval against how fast you need to detect failures.
  • Wrong alarms. Thresholds that are too tight cause false positives on transient problems. Thresholds that are too loose delay detection.
  • Shallow answers. A reply proves only that the process can respond. It does not prove that dependencies work.

A monitor pings a service and declares failure when the echo does not arrive in time.

Diagram source 
sequenceDiagram
    participant M as Monitor
    participant S as Service
    M->>S: Echo request
    S-->>M: Echo reply
    M->>S: Echo request
    Note over M: No reply within time threshold
    M->>M: Declare failure

Checks

Section titled “Checks”
  • The document states how long a pinging component waits for an echo before declaring failure.
  • Timeouts and failure thresholds are configured so transient failures such as network delays do not trigger unnecessary actions.
  • The probe interval is balanced against probe overhead, especially across many instances.
  • The document states whether health checks are shallow or also test downstream dependencies.
Section titled “Related”

Sources

Section titled “Sources”