skip to content

A workload is published by reserving one port number on every host in the fleet — what does that buy, and why cap it?

level: middleimportance: should knowfreq 46%

answer

  1. free, until you count the coordination
  2. nothing allocated externally
  3. one number, the whole fleet
  4. clients get a host list
  5. every host now listens on it

basics

~20 s

It buys external reachability with nothing allocated and no per-workload bill. It costs a fleet-scarce, exclusive port number, a client that must be handed host addresses which change on every resize, and every host listening on that number.

solid answer

~50 s

Reserving a port fleet-wide means the platform answers on that number at every host, so anything reaching any host on it reaches the workload. What you buy is exposure with no allocated external address, nothing per-workload to pay for, and no requirement that the traffic be parseable into requests — which is why it survives as an escape hatch. What it costs: the number is exclusive across the whole fleet and usually drawn from a restricted range, so forty services need a maintained registry of numbers. Clients must be handed host addresses, that set changes whenever the fleet is resized or a host is replaced, and something outside still has to spread traffic and drop departed hosts. Every host is now listening on that number, so the exposed surface is the fleet, not one address. Platform teams cap it for those reasons, not because the mechanism misbehaves.

go deeper

for a junior

Recall that publishing on a port at every host is one way a platform makes a workload reachable from outside, and that no external address is created when it does.

for a middle

Explain why the number is exclusive fleet-wide, where the reservable range comes from, and what the client must be handed instead of a single address.

for a senior

Show what it costs in operation: the maintained registry, the exposed surface across every host, and the balancing work pushed outside the platform onto someone's rota.

for a principal

Decide when the estate tolerates it at all — as a named escape hatch with an owner and an expiry, not as a shape any team may reach for.

## What the shape actually promises The platform takes one port number and promises that **every host in the fleet answers on it** for this workload. Nothing external is created: no address is allocated, no balancer is provisioned, no routing rule is written anywhere. The reservation *is* the publication. This is the fleet-wide form of the idea. Mapping a port on a single machine onto a single container is a different subject with different consequences; what matters here is that the promise is made across every host at once, which turns what looks like a local choice into a scarce, estate-level resource that someone has to administer. ## What you buy - **Reachability with nothing allocated.** No external address, no managed balancer instance, so no recurring per-workload charge from the infrastructure underneath. - **No parsing requirement.** The number is the entire routing decision, so traffic that carries no hostname and is not request-structured travels fine. - **Independence from the entry layer.** It keeps working while a shared edge is being changed, which is why it is often the bootstrap path used to publish something before the edge exists. ## What you pay - **Exclusivity.** While one workload holds the number, no other workload can, because the promise "every host answers on it" has to be unambiguous. Two holders would make the answer depend on which host you reached. - **A finite range.** Platforms carve the reservable numbers out of a range no host process is expected to claim, so the supply is bounded and an estate of forty services ends up with a registry of numbers maintained by humans, not by the platform. - **A fleet-sized exposed surface.** Every host is now listening on that number. Whatever restricts who can reach it has to be applied to every host, not to one address. - **A client that must be told things.** The shape publishes the workload; it does not name it and does not balance it. ## The client's problem, step by step 1. Something must hand clients the list of host addresses, because the shape produces no single external address to publish. 2. Something must spread traffic across that list — either the client itself or a balancer placed outside the platform. 3. That list changes whenever the fleet is resized, a host is replaced, or a host fails, so a stale entry is a connection attempt to nothing. 4. Nothing in this shape removes a dead host from the list; whatever holds the list has to check and prune it. That is the hidden cost. Compared with a provisioned balancer, you have not removed the balancing work — you have moved it outside the platform and made it someone else's standing job. ## Where designs differ Platforms do not agree on what happens when a connection arrives at a host that is running no replica of the workload. Some forward it internally to a host that does, so every host is a valid entry point; others answer only where a replica is actually running, so the client's list must track placement and not just membership. Do not assume either behaviour — it changes what the client has to know and whether a partially-scaled workload is reachable everywhere. ## Fleet-wide port against a provisioned balancer | | Port on every host | Balancer provisioned per workload | |---|---|---| | Allocated externally | nothing | an address and a managed instance | | Recurring bill | none | for as long as it exists | | Who spreads traffic | something outside the platform | the balancer | | What clients are told | a list of host addresses | one stable address | | Effect of resizing the fleet | the client's list is now stale | none the client can see | ## When it is still the right answer It is right where the alternatives genuinely do not apply: traffic a hostname-routing edge cannot parse, a bootstrap path before the entry layer exists, a lab or a short-lived environment where a maintained registry of two numbers is not a burden, or a workload whose clients already hold an authoritative host list for other reasons. It is the wrong answer as a default for an estate, because the coordination cost is linear in the number of workloads and is paid by humans rather than by the platform.

  • Something still has to spread traffic across the hosts. What usually does?
    Something outside the platform: a balancer placed in front of the fleet, or a client that is given the host list and keeps it current. That is the cost people miss — the shape publishes the workload but does not balance it, and whatever fills the gap must learn about hosts joining, being replaced and failing.
  • Why is the range of reservable numbers usually restricted?
    Because the platform has to guarantee the number is free on every host, it carves out a range that host processes are not expected to claim and allocates exclusively within it. The range is finite, so the registry is finite, and no second workload can take a number while another holds it.

saying these in an interview costs you the question

  • Calls the shape free because no balancer is provisioned for it.
  • Assumes another workload may reuse the same reserved number.
  • Expects clients to discover hosts without being handed a list.
  • Believes resizing the fleet leaves the client's host list valid.
  • Confuses it with mapping a port on a single machine.