The Internet Does Not Know Applications

Why BGP does not try to find the fastest path.

Anyone who develops applications inevitably thinks in terms of applications. We talk about APIs, databases, Kubernetes, deployments, or programming languages. Even when we talk about infrastructure, our view often ends at the load balancer or ingress controller. Behind it begins our platform. In front of it – at least in most architecture diagrams – is the internet. A cloud. An arrow. A transition. Perhaps that is exactly why we have become accustomed to viewing the internet as a transport medium. As something that merely carries requests from A to B. But that is not what it is.

Let us take the same request from the first part of this series. A user opens a browser. They enter a URL. A few milliseconds later, an application appears. This apparent simplicity easily leads to a false assumption: that the internet somehow knew where this request belonged. In reality, it never did. Because the internet knows neither applications nor Kubernetes clusters. It knows no containers. No pods. No services. Not even HTTP. At first, the internet knows only one thing: networks.

At first glance, this observation seems almost trivial. Its consequences, however, are far-reaching. Because if the internet does not know applications, another question inevitably follows. How does a request find its way at all?

Many people imagine the internet as a road network. A gigantic map with millions of connections, on which some central authority calculates the shortest route. That idea is intuitive. It is also wrong. There is no global map. No central router. No control center. And no database that knows every link in the internet. Instead, the internet consists of tens of thousands of independent networks. Each of them is operated by a different organization. Internet service providers. Cloud providers. Universities. Mobile networks. Content delivery networks. Companies. They all operate their own networks. They all make their own decisions. And yet, together, they form a single global network. Perhaps that is one of the most elegant properties of the internet. Nobody has the complete picture. And yet every packet finds a path.

These independent networks are called Autonomous Systems. An Autonomous System – usually abbreviated to AS – is not hardware. Not software. And not a data center. It describes a routing domain: a network that makes its own routing decisions. Each AS decides, for example,

which IP prefixes it announces,
which neighbors it connects to,
which paths it prefers,
and which routes it passes on to other networks.

That may sound like a technical detail at first. In reality, this principle forms the foundation of the entire internet.

                +-----------+
                |   AS64500 |
                +-----------+
                     |
        +------------+------------+
        |                         |
        v                         v
   +-----------+             +-----------+
   |  AS64510  |             |  AS64520  |
   +-----------+             +-----------+
        |                         |
        +------------+------------+
                     |
                     v
                +-----------+
                |   AS64530 |
                +-----------+

Each of these networks only knows its direct neighbors. Nothing more.

That raises another question. How does a network know which other networks are reachable? This is where a protocol comes into play that is surprisingly rarely mentioned outside network engineering, even though it forms the backbone of the entire internet: the Border Gateway Protocol, or BGP. The name sounds technical. The basic idea is surprisingly simple. Networks tell their neighbors which IP prefixes they can reach. Those neighbors pass that information on to their neighbors. And in this way, routing information gradually propagates across the entire internet.

        203.0.113.0/24

              announced by

             +-----------+
             | AS65000   |
             +-----------+
               /       \
              /         \
             v           v

         AS65010     AS65020
             \           /
              \         /
                 AS65030

There is no central routing table. The global picture emerges entirely from many local pieces of information.

At this point, a surprisingly common expectation appears. Many assume that BGP now calculates the fastest or geographically shortest route. That would seem logical. But BGP does not do that.

BGP does not optimize for speed.

BGP optimizes for reachability.

The distinction may seem small at first. In reality, it explains a large part of the internet's behavior. BGP does not know a map. It does not know how far Hamburg is from Frankfurt. It does not know where fiber-optic cables run. It does not measure latency. It decides which path to prefer based on routing policies, neighbor relationships, and priorities. A path can therefore be longer than another one. It may run through Amsterdam even though both source and destination are in Germany. Not because BGP made a mistake. But because, from the perspective of the networks involved, that path is preferred – or is the path that is reachable at all. Perhaps this is exactly why good peering is often more important than geographic proximity. A well-connected network can achieve lower latency despite greater physical distance than a geographically closer site with unfavorable transit paths. The quality of a network therefore does not arise from its locations alone. It arises from its relationships with other networks.

Perhaps this idea changes the way we look at modern platforms. A cloud platform does not consist only of servers. It also consists of its network. Its peerings. Its routing decisions. Its integration into the global internet. Anyone building an edge platform is therefore not just building data centers. They are building a network that itself becomes part of the internet. And that is where the story of Anycast begins. Because as soon as a network announces the same prefixes from multiple locations at the same time, something remarkable happens. It is not the application that decides which location processes a request. Not DNS. Not a geo database. But the internet itself. That is what the next part of this series will be about.