Why can two containers on one host both listen on port 8080 without the second bind failing?

## A port number is scoped, not global The instinct carried over from a single machine is that a port number belongs to the machine: if something is on 8080, nothing else can be. That was true because the machine had one network view and therefore one port space. A container normally has a private network view, and a port space comes with it. Binding a port is a claim inside **that** space. So `8080` in one container and `8080` in another are two different ports that happen to share a number, in the same way two houses can both have a room called 'the kitchen'. This has a practical consequence that is easy to under-rate: a workload keeps the port it was written for. No team has to renumber a service because another team got to 8080 first, no configuration has to be rewritten per environment, and the number in the code, the documentation and the health check all stay the same wherever the workload runs. ## Three cases, and what happens in each | Arrangement | Port space | Two listeners on 8080 | |---|---|---| | Two containers, each with its own view | one per container | both bind; no conflict | | Two containers sharing one network view | one, shared | the second bind fails - already in use | | A container running in the host's own view | the host's | conflicts with anything on the host using 8080 | The middle row is the one that surprises people, because the arrangement is chosen for a different reason entirely - usually so that one container can reach another over loopback. Sharing the view to get the loopback also means sharing the port space, and the port numbers have to be deconflicted by hand from that point on. ## What the collision looks like When it does happen, the failure is blunt and local: the process cannot start, and the error says the address is already in use. Three things are worth reading out of that: 1. **It is a bind failure, not a traffic failure.** Nothing was ever connected. The process died at start-up. 2. **It names a port space, not a machine.** The conflicting listener is inside the same view - a container sharing the view, or, for a container in the host's view, anything at all on the host. 3. **Retrying does not help.** Unless the other listener exits, the number stays claimed, so a restart loop just repeats the same failure. ## Why the model chooses scoping over a global registry The alternative designs are worse in obvious ways. A machine-wide registry that hands out ports would make every workload's port dynamic, which means nothing can be written into configuration ahead of time and every caller needs a lookup. Renumbering services per host makes an image behave differently depending on where it lands, which is the opposite of what an image is for. Scoping the number to the view gets both properties at once: - the port is **static and known** - part of the workload's own contract; - the port is **not a shared resource** between unrelated workloads on a host, so density does not require coordination. ## Where the collision moves to Scoping does not abolish contention, it relocates it. As soon as a port has to answer somewhere shared - on the host itself, or on an address other hosts can route to - that shared place has one port space again, and two workloads wanting the same number there do collide. Those hops are separate mechanisms with their own leaves; the point for this one is that the inside-the-view number and the outside-the-view number are different things and need not match. ## What is still unique per container One last precision, because it is a common muddle: containers with separate views also have separate addresses, so even if the platform wanted to route by port alone it would not have to - the address distinguishes them. The number is free precisely because the address is not. Two containers sharing one view are the mirror image: one address between them, so the number is the only thing left to tell their listeners apart, and it must therefore be unique.