IP address
A number that identifies a machine on a network, like 203.0.113.10. To send data anywhere, this is what you actually need — names don't work at this level.
Bonus lesson · Optional · No Docker required
How did your request even find Silicon Lanes?
Every lesson so far started the moment a request arrived at one of our containers. This one rewinds back onto the open internet — and answers the question Lesson 7 left hanging: our CDN was a single box, so wasn't that just one more single point of failure?
Short version: in the real world it isn't one box, and the reason why is genuinely clever.
Start here
Four words, in plain English.
Everything below is built out of these. Nothing fancy yet.
Domain name
The human-friendly name, like yourapp.com. Easy to remember, useless to the network on its own. It has to become an IP address first.
DNS
The system that turns a domain name into an IP address. The internet's phone book: look up a name, get back a number.
BGP
How networks tell each other which addresses they can reach. Once you have a number, this is what decides the route your data actually takes to get there.
Step one
What actually happens when you visit a website.
Someone types yourapp.com and hits enter. Before anything else can happen, that name has to become a number.
Browser“where is yourapp.com?”
DNS“it's 203.0.113.10”
Your server203.0.113.10, London
That's it. The browser asks DNS, DNS gives back one simple address, and the browser opens a connection to it. Every website visit you have ever made started with those two steps.
Whoever is asking — Bengaluru, Berlin, Boston — DNS returns that same number, and everybody's traffic converges on that one machine in London.
The problem
One machine. So one bad day takes down everything.
Look closely at what we just built, because it's the same shape you've spent seven lessons trying to eliminate.
Server healthy
Everyone
London
Site loads
Server down
Everyone
London
Nothing. For everybody.
DNS is still cheerfully handing out 203.0.113.10 to every person who asks. It has no idea the machine behind it is on fire. Everyone dutifully connects to an address where nobody is answering.
This is a single point of failure, and it's the biggest one yet. In Lesson 3 a dead Catalog replica was survivable — the load balancer just used another one. Here there is no “another one.” One address, one machine, one outage, whole site gone.
The fix
Serve that same address from many places at once.
Instead of giving each location its own address, you give every one of them the same address. That is what anycast means.
203.0.113.10 in Mumbai. The same 203.0.113.10 in Frankfurt. The same one again in Virginia — all three running at the same time, all three genuinely answering to that number. DNS still has exactly one address to hand out, and still hands the identical one to everybody.
Someone in Bengaluru
DNS says: 203.0.113.10
Someone in Berlin
DNS says: 203.0.113.10
Mumbai203.0.113.10
Frankfurt203.0.113.10
Virginia203.0.113.10
Same address in all three cities, all live at once. DNS gave both people the identical answer — the network is what sends them to different buildings.
So how does anyone end up anywhere in particular? That's BGP — Border Gateway Protocol — the system networks use to tell each other which addresses they can reach. Each location advertises “I can serve 203.0.113.10,” that message spreads outward network by network, and every router along the way ends up knowing several routes to that one address. When your data arrives, each router simply forwards it down the shortest route it knows.
From Bengaluru the shortest route ends at Mumbai. From Berlin it ends at Frankfurt. Nobody configured that per person — it falls out of the routing.
Which gets us two things at once, from a single change:
Redundancy
Several machines now stand behind one address, in different cities, on different power grids and different networks.
Geographic performance
Everyone is served from whichever of those is closest to them, so the distance problem shrinks at the same time.
Anycast is not a CDN feature — it's a general internet technique. Public DNS is the clearest example: 8.8.8.8 and 1.1.1.1 are each one address served from hundreds of locations worldwide. CDNs lean on it heavily, but they didn't invent it.
The payoff
And there's the single point of failure, finally gone.
A location advertises that address only while it is healthy. The moment it isn't, it stops advertising — and every route pointing at it quietly disappears.
Normally
Bengaluru
Mumbai
Site loads
Mumbai offline
Bengaluru
Mumbai
Frankfurt
Site still loads
Compare that with the outage two sections ago. Same failure — a location dies — but now the address survives it, because the address was never tied to that one building in the first place. Nobody changes a DNS record. Nobody edits a config. Nobody has to do anything at all. Routers recalculate, traffic lands somewhere else, usually within seconds.
This is what makes the availability numbers people quote actually achievable:
Uptime
Downtime allowed per year
Roughly what it takes
99%about 3.7 daysOne machine, and some luck
99.9%about 8.8 hoursRedundancy inside one location
99.99%about 53 minutesMultiple locations, automatic failover
99.999%about 5 minutesMany locations, rerouting in seconds
Those bottom two rows are effectively unreachable with one machine in one building — 53 minutes a year is less than a single reboot plus one bad deploy. Published CDN service-level agreements sit in the 99.9% to 99.99% range, some vendors advertise a 100% uptime SLA on their top tiers, and independent measurements of the major providers cluster close to 99.999%. Anycast is a large part of why any of that is possible.
That's also the answer to Lesson 7's open question. Our local CDN really was one container, and really was a SPOF. A real one isn't a box at all — it's an address that hundreds of buildings answer to, where losing any one of them is a routing update rather than an outage.
Two honest caveats. Connections already open to the failed location do break and have to be re-established, so people see a blip rather than a clean handover. And a “100% uptime” SLA is a commercial promise backed by service credits — not a claim that nothing ever fails.
Worth knowing
Anycast isn't the only way to do this.
The same goal — many locations behind one front door — can be reached from the opposite direction: keep ordinary addresses, and put something in charge of choosing between them.
Anycast, via BGP
Every location shares one address, and the network decides who reaches which, through routing. No device is in charge — the choice falls out of BGP.
Unicast, via a traffic manager
Every location keeps its own distinct address. A device such as an F5 BIG-IP watches their health and load, and hands out whichever address it wants you to use. The choice is made by an appliance you control.
Roughly, the trade is control versus reach. A traffic manager gives you precise, tunable rules and a dashboard to watch them in — but it's a system you have to run, and it becomes one more thing that can fail. Anycast needs no such device, but it does need address space and routing arrangements you almost certainly don't have unless you're a provider.
The whole journey
Step through it, start to finish.
The complete trip — from typing a name, across the internet, into the architecture you built in Lessons 6 and 7. Click any box to see what it's doing.
Out on the open internet
Your infrastructure (Lessons 6 & 7)
L4
L7
Step 1 of 6
You type a name. Your browser has no idea what that means yet.
It has yourapp.com, which is a word, and words don't work on a network. Before a single byte goes anywhere, that word has to become a number.
Bringing it home
Where this meets what you already built.
Everything in this lesson happens before Lesson 7's first line of code runs. DNS and BGP decide which CDN location a person reaches. From the moment their connection lands there, it's the story you already know: check the cache, and on a miss, forward to the origin — the Edge Load Balancer, the API Gateways, the Catalog Load Balancer, the replicas.
Running locally, all of that collapses to 127.0.0.1. One machine, no cities to choose between, no BGP in sight. But the shape is identical, and every decision still gets made — just by Nginx on your laptop instead of by routers spread across the planet.
The terms from this lesson
- IP address
- A number identifying a machine on a network. What your computer actually needs to send anything.
- Domain name
- The readable name for a site. Must become an IP address before it's usable.
- DNS
- The internet's phone book: give it a name, it gives back an address.
- Anycast
- The same address, live in many locations at once. Routing, not DNS, decides which one you reach.
- BGP
- How networks tell each other which addresses they can reach, and how routers pick between competing paths.
- Point of Presence (PoP)
- A physical site where a provider accepts public connections. Large CDNs run hundreds.