Anycast, without the magic
Anycast is one of those words that sounds like a trick until you draw the BGP table. The short version: several machines announce the same address, and each network on the internet picks whichever announcement looks best from where it sits. There is no central load balancer and no shared state between the machines. The routing system is the load balancer.
What it actually optimizes
Anycast optimizes for topological distance, not for application health. A network will usually choose the shortest AS path, which often correlates with latency, but not always. A nearby node with a congested transit link can lose to a farther one with a cleaner path. This is why anycast products publish real-time measurements instead of promising a fixed latency.
Where it breaks
The classic failure is a route change in the middle of a connection. If a network withdraws one announcement, new connections move to another node, but existing TCP sessions stay pinned to the old one until they time out. For stateless request/response traffic that is fine. For long-lived sessions it is a design constraint: either keep the session state replicated, or make the client reconnect quickly and cheaply.
The second failure is less obvious. Because the same address can land on different machines for different users, per-IP rate limits and access rules are only coherent if every node shares the same view of the client. If they do not, a user behind a carrier NAT can appear as a new client on every request.
A useful mental model
Think of anycast as a routing hint, not a guarantee. It is excellent for absorbing volumetric attacks, terminating TLS near users, and hiding a pool of origins. It is a poor fit for anything that assumes a stable path. Design the protocol so a mid-flight node change is survivable, and the rest is ordinary distributed systems work.