You are on the traffic and edge SRE team of a professional social network with roughly 900 million members, about 40 edge PoPs and four data centres (two in the US, one in Europe, one in Singapore). Members in Indonesia are about 4 percent of global traffic and are served from PoPs in Jakarta and Singapore using anycast plus GeoDNS. At 09:40 UTC their p75 feed load time went from 1.9 s to 3.4 s; no deploy is tagged against that time.
The interviewer asks“Since about 09:40 UTC, real-user monitoring shows feed load time for members in Indonesia has nearly doubled, while every other country is flat and server-side latency in all our data centres looks normal. Walk me through how you'd investigate it, what you'd do first to help members, and how you'd get to root cause.”
Server latency is flat, so I treat it as a path problem until proven otherwise. I slice RUM by ASN, served PoP and platform, and break the page load into DNS, connect, TLS, first byte and download, because the phase that grew tells me the layer. Then I check what changed at 09:40 on our side and the internet's: PoP mapping, GeoDNS answers, BGP routes for our prefixes, edge-to-origin DC mapping and TCP retransmits for those prefixes. As soon as I know the bad leg I steer traffic around it, by DNS override, BGP community or origin remap, and then take the evidence to the ISP or transit provider for the root cause.
A free account unlocks the rest of it, and saves your progress across every track.
ping Check if a host answers and how fasttraceroute Trace the routers between you and a hostdig Query DNS and read the full answernslookup Look up DNS names quicklycurl Make HTTP requests and debug APIswget Download files reliablyssh Log in to remote servers securelyss See listening ports and open connections