What actually disappeared at 14:07?
Imagine the affected service owns an example prefix that its edge network ordinarily announces to two transit providers. At 14:07, a configuration change withdraws that prefix from both peers. The servers have not moved and the TLS certificates have not expired. But upstream routers stop advertising that route onward. Routers that have no acceptable alternative may drop traffic because they no longer know where to send it. Others might still have a valid alternate route and continue reaching the service.
A withdrawal is a control-plane event. The failed browser request is a data-plane observation. Don't mix them. A BGP session can also flap, a route can be filtered, an inappropriate announcement can redirect traffic, and a valid path can exist while its actual forwarding path is broken. Those incidents have different fixes. The phrase "BGP is down" explains almost nothing until we identify which prefix, neighbor, advertisement and policy changed.
This is why DNS fixes are often irrelevant. Suppose api.example.com still resolves to the correct public IPv4 address. DNS maps a name to an address, but it does not ensure the address's prefix is advertised to the client's networks. Lowering the DNS TTL does not repair a missing route. DNS steering might move traffic to an independently reachable alternate prefix, but only if that alternative exists, the clients resolve it again, and their existing connections and caches allow migration.
Evidence must come from outside the failing network
First I would group customer failures by source autonomous system, geographic region and address family, then compare those groups with successful clients. Is the problem global or concentrated among networks that share an upstream? Did IPv6 continue to work while IPv4 failed? Does the edge see fewer incoming SYN packets, or does it receive connections and reject them? If edge requests disappear while local health checks stay green, upstream reachability becomes a strong hypothesis.
Next I would inspect our own route advertisements and BGP neighbor state. Check exactly which prefixes we intend to announce, when announcements changed, and whether our peers accepted or filtered them. Use independent route collectors and looking glasses to see whether the expected paths are visible from other autonomous systems. Traceroute and TCP probes can help, but ICMP filtering and different forwarding paths mean a stopped traceroute is not conclusive on its own.
A useful incident timeline puts application incoming request rates next to public-route observations. A decrease in traffic to a prefix shortly after its withdrawal is causal evidence when supported by router logs and external collectors. A healthy process dashboard cannot contradict that evidence because it observes a different layer.
Defensive controls have limits
Many incidents are prevented by ordinary routing hygiene: approved prefix lists, outbound route filters, change review, maximum-prefix protections where relevant, independent peers, route-monitor alerts and a rehearsed rollback. RPKI route-origin validation can help reject announcements whose origin AS is unauthorized by a Route Origin Authorization. But it does not guarantee all paths are valid or prevent you from accidentally withdrawing your own correctly authorized prefix. Origin validation addresses a narrower problem than total internet routing correctness.
Redundant ingress must really be independent. Advertising the same prefix to two providers helps only if they do not share the failing control plane, route filter or operational mistake. An alternative service address on a separate prefix can offer another recovery option, but it introduces steering, state and certificate considerations. An alternate region whose traffic still funnels through the same broken edge is not a separate failure domain.
For a Staff or Principal interview, I would describe a rollback that restores the known-good announcements, verifies acceptance by each neighbor and waits for external reachability measurements rather than declaring success when a local router shows the session as established. Convergence is not an instantaneous global switch. Clients in different networks can recover at different times.
The lesson isn't that every backend engineer must configure BGP. It is that availability needs an end-to-end path. When no packets reach a healthy service, the correct response is to inspect the routing layer before adding application replicas or increasing API timeout budgets.
