A request that normally takes 50ms intermittently takes 5 seconds, with no error and the backend showing nothing unusual. Walk me through how you'd diagnose this across the network path.

technical-conceptual · Senior level · software-engineering

What the interviewer is really asking

Assesses systematic network debugging at senior level — distinguishing client, DNS, connection-setup, TLS, queueing, and retransmission causes — and the discipline to localize the latency with evidence rather than guessing.

What to say

• Localize before theorizing: split the wall-clock time into DNS resolution, TCP connect, TLS handshake, time-to-first-byte, and transfer using request timing or a packet capture, so you know which segment owns the 5 seconds.
• Reason about common intermittent culprits — DNS timeout falling back to a slow resolver, connection-pool exhaustion forcing fresh handshakes, a retransmission timeout from packet loss (often a near-1-second multiple), or head-of-line blocking on a shared connection — and check whether the 5s clusters on specific hops or hosts.
• Correlate with infrastructure signals: load-balancer and proxy queue depth, connection limits, and whether the slow requests share a pod, AZ, or NAT path, so you separate a client-side or path issue from the backend that looks healthy.

What to avoid

• Immediately blaming the backend or 'the network is slow' without decomposing where the time is actually spent.
• Forgetting the client and connection-setup path — DNS, pooling, and TLS handshakes are frequent intermittent-latency causes that backend metrics never show.
• Adding a blanket retry or raising timeouts as the first move, which masks the cause and can amplify a queueing or retransmission problem.

Example answers

Strong: Since the backend looks clean, I'd suspect the path or connection setup. First I'd break the 5s into DNS, connect, TLS, and TTFB from request timings or a capture. A retransmission timeout shows up near a 1-second multiple; connection-pool exhaustion shows up as repeated fresh TLS handshakes. I'd then check if the slow calls cluster on one AZ or NAT path and look at LB queue depth — only then change timeouts, and never with a blind retry that could amplify the problem.

Weak: If it's intermittent it's probably just network flakiness, so I'd add a retry with a higher timeout so the slow ones eventually succeed and stop paging us.