The earlier Foundations articles, How computers work: Feynman’s high-speed filing clerk and How computers turn 0s and 1s into words and pictures, explored how a computer follows instructions and represents information as stored values. Moving that information to another computer raises a different problem: the machines do not share memory, and no direct connection need exist between them. Feynman’s filing clerk can open a numbered drawer to find something already stored nearby. To obtain information held by a distant computer, however, the clerk must send a request and wait for a reply, more like writing to another office than opening a second drawer. Processing may be ready to continue long before the answer arrives.
The internet makes such exchanges possible by connecting networks run by different organisations. Information can pass from the network a device first joins through several others, reach a service able to respond, and then return by another sequence of connections. Understanding both the journey and the systems that supply the answer explains why access differs between locations, why some requests are slow and why apparently unrelated services can fail together.
From the device to the wider network
A phone, laptop or other device begins with a local connection, often through Wi-Fi, a mobile network or a cable. From there, nearby networking equipment forwards traffic towards a wider network. For home and office connections, an internet service provider (ISP) commonly provides the connection to the wider internet; on mobile connections the provider’s network serves a similar role. Each provider can exchange traffic with other networks, allowing communications to cross organisations and great distances without a dedicated physical connection between the two end devices.
The internet works at this scale because many communications can use the same underlying links and equipment. A video call, a message, a file download and a service request may all share part of the network, drawing on its available capacity. To direct each exchange, Internet Protocol (IP) supplies destination addresses, and routers use those addresses to choose where traffic goes next. A service can have several addresses, and several machines can appear behind a single address; an address makes delivery possible without identifying a unique physical route or machine.
How a service name becomes an address
Before an application can contact a named service such as example.com, it normally needs a network address. The Domain Name System (DNS) helps find one, much as looking up an office’s address makes it possible to send a letter. An address may already be saved on the device, or the device can ask a DNS resolver. The resolver may return a cached answer or consult other name servers; information about names is distributed among many systems, not stored in a single worldwide directory. A service may have several valid addresses, and they can change over time.
When the necessary answer is not cached, finding it can involve further network exchanges and add time before the application sends its request. A failed lookup can prevent access by name even if the destination systems are otherwise working. Finding an address still leaves the route to be determined. Once the application has an address, it sends traffic towards that destination, and routers along the way use their own routing information to select onward connections. The name lookup establishes neither which path the traffic will take nor whether the service will answer.
How networks forward information
Once the destination address is known, traffic begins its journey through a device’s local gateway, usually a router. The gateway forwards it to another router, which chooses the next connection using the destination address and its own routing information. The sequence can cross networks operated by multiple organisations: a local provider may hand traffic to another carrier, which carries it towards the network serving the destination. Each router makes a local forwarding decision. There is no central control room dispatching the complete journey for every request. Different communications may share some of the same links even when they come from different sources and ultimately go to different places.
A forwarding step between routers is often called a hop. A larger hop count does not, by itself, imply a longer delay; the distance travelled, the connections available, congestion and the location of the answering system also matter. Networks exchange information about which destinations can be reached through which neighbours. When a link or a network fails, that information may change, and routers may adopt different onward paths if usable alternatives exist and operator policies permit them. Updating those directions can take time, and some destinations have no available alternative. Even when a request reaches its destination, the reply may follow a different sequence of routers on its return.
Where answers come from and why they take time
When a request reaches the infrastructure serving its destination, some system must prepare a response. It might retrieve stored information, carry out a calculation, check permissions or update a record. The organisation offering the service may operate the machines itself, or depend on a hosting provider to do so. A working network path therefore cannot guarantee a timely answer: software, storage and other systems can become slow, overloaded, misconfigured or unavailable after the request arrives. Even for public material, repeatedly asking the same distant machine for an unchanged image or file can waste time and network capacity.
Copies of suitable content can be kept in different locations. A content delivery network (CDN) can answer some requests from a stored copy rather than contacting the original source, usually called the origin. When no suitable copy is available, the delivery system may need to retrieve the item from another cache or from the origin before it can respond. Other operations, such as signing in, changing stored data or requesting up-to-date information, may require fresh work. The systems storing, processing and delivering information can belong to different organisations while appearing as one service. The answer then travels back through the network to the requesting device, which interprets it.
The same service can feel quick from one location and sluggish from another. One user may reach a server or nearby CDN location through well-connected networks, while another’s request crosses longer or more congested connections, or takes a less direct route. Network latency describes the time spent travelling through the network; both the outward request and the response contribute to the waiting time. The geographically closest server is therefore not necessarily the quickest to reach. The number of routers encountered provides some information about the journey but cannot substitute for knowing how long the exchanges actually take. A name lookup can add its own wait before the request begins when no suitable cached answer exists.
Delivery time also includes work performed after the request arrives. The answering system may have to read storage, generate a result, retrieve an uncached item or wait for another service. A connection capable of transferring large amounts of information quickly cannot eliminate delays in those steps. If an answer takes too long or never arrives, the application may report a timeout and may retry, depending on its design. Where processing and information are held therefore affects more than speed: it determines which systems must be available for a request to succeed. That dependency becomes especially important when several services rely on the same infrastructure.
Why services can fail together
A shopping website, a banking app and a video service can have separate owners and purposes yet depend on the same piece of infrastructure. Providers such as Amazon Web Services, Microsoft Azure and Google Cloud supply computing and storage; Cloudflare, Akamai, and Amazon CloudFront provide forms of content delivery and other network services. These categories can overlap, and providers operate many distinct components. Naming a supplier therefore establishes neither a common technical dependency nor the cause of a particular failure. The critical question is which components each service actually requires to perform a particular operation.
A single point of failure is a necessary component for which an operation has no effective alternative. It need not be one physical machine. A platform can run on thousands of computers yet depend on one logical system for identity checks, configuration or access to stored information. If that system fails, machines that remain healthy may still be unable to complete a request. Geographical separation helps only when important dependencies are independent enough: several data centres might all rely on the same control service, just as several applications can share a supplier but use different, unaffected components. Resilience depends on which failures a design can tolerate, rather than the number of machines or sites it contains.
Failures at different levels can have much the same visible effect. An access network may lose a route to healthy services; naming, hosting or delivery infrastructure can stop functioning; or an individual application may fail even though its network remains available. An outage affecting several organisations therefore suggests possible shared dependencies, but does not identify which one failed.
On 20 October 2026, a power event disrupted Google Cloud services in its London region while customers of Revolut, Lloyds and HSBC reported problems accessing banking services. Google’s preliminary incident report described how loss of one data-centre zone also disrupted services elsewhere in the region, as work shifted to remaining infrastructure and some regional systems still depended on components in the unavailable zone. Reuters reported a connection between Revolut’s outage and the Google Cloud incident; the exact failure paths affecting each institution were not publicly established.
An incident of that kind also shows why adding machines or alternative routes is insufficient on its own. Another network route cannot repair a failed application, and additional servers may do nothing if all of them rely on the same control system. A backup matters only when it remains usable after the particular dependency in question fails. When evaluating reliability, the useful question is which component can become unavailable without stopping the operation the service is expected to perform.
How news apps get articles
A news app offers a concrete illustration of how software architecture changes the reach of a failure. It may retrieve material directly from several publishers, contacting each source as needed. If one publisher becomes unavailable, requests to the others can still succeed, provided those retrieval paths remain operational. This does not make the publishers completely independent; they may share naming, hosting or delivery infrastructure. It does mean that the application has not introduced one additional remote service that must be available to fetch every publisher’s new material.
An alternative news app may obtain the same publishers’ material from a central platform, which gathers it and then serves it to the app. The platform might use many servers and locations, but if the application has no alternative path for fresh retrieval, the central service becomes a necessary dependency for every source shown through it. A failure there can stop new material from arriving even while the publishers continue to operate. Readers may see almost identical interfaces in both designs; the difference lies in the systems that must work for the next request to succeed.
Material already saved on the device can remain readable during either kind of outage, though that does not establish that fresh material can be retrieved. The delivery architecture also affects which parties handle information. Encryption commonly protects communications while they travel across networks, limiting what unrelated operators along the route can read. A central delivery platform that terminates or processes a connection may nevertheless be able to access the content it serves; encryption in transit does not determine whether that platform is trustworthy or whether its information is accurate. The distinction matters for availability and for how a service handles data, even when its interface reveals neither.
The bottom line
Internet access depends on more than a working connection from a device. Each useful response involves a path through independently operated networks and a set of systems able to supply the answer. Delays arise along both parts of that chain; failures spread as far as their necessary dependencies. The architecture matters most where it is least visible: several organisations may rely on one critical component, while one application may turn separate sources into a single point of dependence. Understanding where an answer actually comes from, and what could stop it arriving, makes apparently unrelated outages less mysterious and designs easier to judge.
Things you should know
| No. | Term | What it means |
|---|---|---|
| 1 | Content delivery network (CDN) | Can serve copies of suitable content from different locations instead of always contacting its original source. |
| 2 | Domain Name System (DNS) | Helps find an address for a name such as example.com; it does not choose the route. |
| 3 | Internet Protocol (IP) | The addressing system that helps carry information towards its destination across networks. |
| 4 | Internet service provider (ISP) | The company that provides your connection to the wider internet. |
| 5 | Single point of failure (SPoF) | Something an operation needs but has no effective alternative for. If it fails, that operation stops. |
References
- Google Cloud Service Health (22 October 2026). Preliminary incident report on the disruption of 20 October in the europe-west2 region. ↗
- Reuters (21 October 2026). “Europe's financial regulators query Google over cloud outage that hit banks.” ↗
- Synergy Research Group (30 July 2026). “Q2 Cloud Market Passes $143 Billion; Highest Growth Rate in Eight Years.” Worldwide cloud-infrastructure-services revenue shares for Q2 2026: Amazon 28%, Microsoft 20%, Google 15%. ↗
- W3Techs (accessed 22 October 2026). “Usage statistics and market shares of reverse proxy services for websites.” Measures observed website use of services including Cloudflare, Amazon CloudFront, Fastly and Akamai, not CDN revenue or traffic shares. ↗