Why DNS likes this arrangement
A DNS query is normally short and often independent of earlier queries. If it reaches a different healthy anycast resolver or authoritative server, that new location can answer without relying on the previous site's per-connection state. Anycast can reduce network distance and distribute some load. It also makes service observation tricky: a test from one network only confirms the node that its routing path currently selects.
An HTTP session is different. Suppose a client has a TCP connection to a CDN edge in city A. The server in A holds sequence-number state, congestion and flow-control state, TLS session state and possibly application routing decisions. The IP address in the client's socket remains unchanged. But after a route withdrawal or policy change, the client's packets begin arriving at city B. B usually has none of A's TCP connection state. Depending on the edge implementation, it may drop the packets or send a reset. The client experiences a broken connection despite unchanged DNS and destination IP.
Anycast does not necessarily break every long-lived connection. If the network keeps a flow on a stable path, or the operator has a design that preserves the relevant state, the connection can continue. The important risk is that routing changes can alter destination ownership in ways ordinary application load balancers do not control. That risk is greater for protocols whose sessions last much longer than the expected stability of the path.
The drain problem is not an on/off switch
Now plan maintenance for city A. We want new traffic to avoid A while not dropping active customer uploads. If we simply withdraw the site's announcement, remote networks may begin choosing city B. The withdrawal eventually changes the catchment, but it doesn't carry existing TCP state to B. Leaving A's processes running is not enough if the packets no longer arrive there.
A safer policy depends on the service. For stateless DNS, graceful site withdrawal is usually easier because requests are brief. For an HTTP upload, application-level resumability, smaller bounded transactions, an edge proxy terminating the connection, and controlled routing or draining can mitigate disruption. An architecture might keep a stable unicast address for sensitive sessions while using anycast for discovery or initial entry. Another might arrange stable edge termination and keep mutable user state in a separate backend. These are deliberate compromises, not universal recipes.
DNS-based steering is one alternative. It can return different site-specific addresses to clients, giving the operator more direct control over new connections. But cached answers can continue directing new connections to an old address, and established connections do not re-resolve DNS merely because a record changes. DNS steering and anycast can also be combined: DNS selects an anycast-enabled regional footprint, while internal routing selects an edge. Neither makes a stateless routing protocol a state replication system.
How I'd verify the incident
Record which anycast point of presence handled each request, not just the destination IP. Expose edge identifiers in safe response metadata or in internal telemetry. Measure traffic and resets by source autonomous system and network path. If an edge route changed at 14:07 and one population's established connections began resetting at the same moment, that is a more useful clue than a global average health score.
Test maintenance from multiple source networks, including clients with established sessions before withdrawal and new clients afterward. Watch whether packets continue to reach A, move to B or briefly have no route. A routing change can propagate at different speeds and affect different source networks differently. Also monitor connection age, active uploads and failed resumptions, so a successful withdrawal does not hide a user-visible incident.
The interview tradeoff is between coarse-grained network distribution and session ownership. Anycast excels where independent sites can answer a request with little location-specific state. When an application requires a long-lived stateful session, the design must assume that the network may change which site receives its packets. A stable service IP is not a promise of a stable server.
