A crypto exchange sees intermittent elevated latency to a market-data provider. Servers are healthy, the provider reports no issues, and the problem appears in bursts. How would you diagnose it?

The systematic approach

Establish where the time goes before hypothesising why. The candidates are DNS resolution, TCP connection setup, TLS handshake, request transmission, server processing, response transmission, and client processing. Each has a different cause and a different fix, and most teams guess rather than measure.

• Instrument the client to break the request down by phase. A latency histogram per phase turns a vague complaint into a specific one, and it usually identifies the phase in one observation window.
• Correlate with connection age. If latency spikes coincide with new connections, the cause is setup — handshake, DNS, or a pool that is churning. If it affects established connections, it is transmission or the server.

The specific causes that produce bursty latency with healthy endpoints

• Packet loss with retransmission. A small loss rate produces occasional multi-hundred-millisecond delays from retransmission timeouts, invisible in averages and dominant in p99. Loss is often at a single hop and invisible to both endpoints.
• Connection pool exhaustion, where requests wait for a connection rather than for the network. The symptom is client-side latency with no corresponding server-side latency — the single most useful correlation to check, because it immediately separates network problems from local ones.
• DNS resolution latency or a failing resolver in a set, producing periodic slow requests when the bad resolver is chosen.
• Middlebox behaviour — NAT table pressure, firewall connection limits, an intermediate proxy — which is invisible to both ends and produces exactly this pattern.
• Provider-side load shedding or rate limiting that manifests as latency rather than as an error.

The tooling that resolves it

Continuous path measurement rather than an ad-hoc trace during the incident: per-hop latency and loss over time, so the incident can be correlated with a specific hop after the fact. Plus a passive baseline from before the problem, because a measurement with nothing to compare against proves very little.

The organisational part

"The provider reports no issues" usually means their aggregate metrics are fine, which is compatible with your traffic being affected. Bring specific evidence — timestamps, source addresses, per-hop measurements — since a report of "sometimes slow" is not actionable for them and will be closed.