skip to content

At what point do you stop adding point-to-point links between private networks and put a transit hub in the middle?

level: principalimportance: should knowfreq 42%

answer

  1. count pairs, not networks
  2. links grow quadratically, attachments linearly
  3. a star is not a mesh
  4. attachments carry a standing charge
  5. the worst estate is half of each

basics

~20 s

When the pairs that must talk stop being a short list. Links grow with pairs and hub attachments grow with networks, so a hub wins on arithmetic — at the price of a standing charge per attachment, a shared route-table ceiling and one component in everybody's path.

solid answer

~50 s

Count pairs, not networks. A full mesh needs a link per pair, so it grows quadratically, while a hub needs one attachment per network. Six networks is fifteen links against six attachments; twelve is sixty-six against twelve. But the trigger is not a network count, it is the **shape of the demand**: if only three pairs genuinely talk, direct links stay simpler and each data path is independent of everything else. A hub is the right answer when the talkers are becoming many-to-many, when new networks arrive regularly, or when a shared services network must be reachable from all of them. What you buy it with is a per-attachment standing charge that accrues whether traffic flows or not, a route-table entry budget shared across the estate, and a single component that sits in everyone's path and has one owner and one change window.

code

pseudocode · 13 lines
pseudocode
function fullMeshLinks(networkCount):
    return networkCount * (networkCount - 1) / 2

function hubAttachments(networkCount):
    return networkCount

for n in [4, 6, 12, 20]:
    print n, fullMeshLinks(n), hubAttachments(n)

# 4  ->   6 links,   4 attachments
# 6  ->  15 links,   6 attachments
# 12 ->  66 links,  12 attachments
# 20 -> 190 links,  20 attachments

go deeper

for a junior

Know the shape of the argument: joining every pair of networks directly needs a link per pair, which grows fast, while a hub needs one attachment per network.

for a middle

Do the arithmetic and state the catch: six networks is fifteen links against six attachments, but the count only matters if every pair genuinely needs to talk.

for a senior

Argue from the demand graph and the costs a hub adds: a standing charge per attachment, a shared entry budget, and reachability that now has to be withheld deliberately.

for a principal

Make it a standard others follow: decide from the pair list and the arrival rate, publish how a new network joins, and name the condition that would make you revisit it.

## The arithmetic everyone quotes The textbook argument is a counting argument. Connecting networks pairwise takes one link per pair, so the link count is `n * (n - 1) / 2`, while attaching them to a hub takes one attachment each. | Networks | Full mesh links | Hub attachments | |---|---|---| | 4 | 6 | 4 | | 6 | 15 | 6 | | 12 | 66 | 12 | | 20 | 190 | 20 | The curve is real, and at twenty networks nobody is seriously maintaining a hundred and ninety links. But the counting argument answers the wrong question, because it assumes every pair must talk. ## The question that actually decides it The deciding input is the **shape of the demand**, not the number of networks: - If the real requirement is many-to-one — every network needs a shared services network and nothing else — that is a star already, and a star needs `n - 1` links. The mesh curve never bites, and direct links keep each path independent. - If the requirement is genuinely many-to-many, or is drifting that way as teams discover each other, the pair count is on the quadratic curve and the hub is inevitable. The only question left is when you pay for it. - If new networks arrive on a schedule — an acquisition every few quarters, a new environment per product — then each arrival costs `n` new links in a mesh and one attachment on a hub. The rate of arrival matters more than today's count. The practical trigger is the moment a new network's onboarding requires touching more than a couple of existing networks. That is the estate telling you it has become a graph. ## What a hub costs A hub is not free, and pretending it is produces the second-worst outcome after the unmaintainable mesh: - **A standing charge per attachment.** Each attachment accrues whether or not a byte crosses it, so an estate that attaches speculatively pays monthly for potential. - **A shared entry budget.** Every attached network's ranges must live in the hub route table that serves them, and that table has a ceiling the whole estate now shares. - **Reachability granted by default.** Attachments associated with one hub route table can reach each other. Separation stops being a property of "we never built a link" and becomes something you have to express deliberately with segmented route tables. - **One thing in everybody's path.** The hub has an owner, a change window, and a place in every incident review. A mesh has no shared component to fail; a hub has exactly one. ## When point-to-point is still right Direct links remain the better answer when the pairs are few and stable, when two estates are joined for one purpose, or when a pair needs a data path that is independent of any shared component. They are also the faster answer during a merger deadline: a link between the two networks that actually have to talk can be created and tested in an afternoon, while designing the hub, its route tables and its attachment standard is a project. The failure mode to avoid is the accidental middle: a handful of links plus a partial hub, with some networks attached and some peered, and no written rule about which mechanism a new network gets. That estate has the mesh's complexity and the hub's shared failure domain at the same time, and nobody can answer 'can A reach C' without reading configuration. ## How to decide it, once 1. List the **pairs** that genuinely exchange traffic today, not the networks. Then list the pairs you expect within a year. 2. If both lists are a star or a short list and the arrival rate is near zero, build the links and write down the count at which you will revisit. 3. If either list is many-to-many or the arrival rate is steady, design the hub before the next arrival, including which attachments share a route table and which do not. 4. Either way, publish the rule for how a new network joins, so the accidental middle never forms. The decision is a standard, not a configuration. Its value is that the tenth network's onboarding looks like the second's.

  • Twenty networks each need only a shared services network. Does the mesh argument apply?
    No. That demand is a star, which takes nineteen links, and the quadratic curve never appears. A hub may still win for other reasons — a single place to manage routes, one attachment per new arrival — but the counting argument is not one of them, and quoting it here is a sign of pattern-matching rather than measuring.
  • What is the worst topology an estate can drift into?
    A partial hub alongside surviving direct links, with no rule for which a new network gets. It carries the mesh's configuration sprawl and the hub's shared failure domain simultaneously, and nobody can answer whether one network reaches another without reading configuration in several places.
  • What changes about separation when you move from links to a hub?
    Separation stops being the default. Two networks were unreachable because nobody built a link; once both attach to a hub and share a route table, they reach each other unless you say otherwise. Segmenting hub route tables is how the previous isolation is re-expressed, and it has to be designed rather than inherited.
  • How does the arrival rate of new networks affect the decision?
    It often decides it. At a steady arrival rate, each new network costs one link per existing peer in a mesh and one attachment on a hub, so onboarding cost is flat on a hub and climbing in a mesh. An estate expecting acquisitions should design the hub before the one that forces it.

Direct phone lines between every pair of offices work until you have a dozen offices; a switchboard replaces them with one line each. The switchboard is also the one thing whose failure silences everybody.

saying these in an interview costs you the question

  • Quotes the quadratic link formula when the real demand is a star
  • Treats a hub as free because it replaces many links
  • Forgets that attachments sharing a hub route table reach each other by default
  • Leaves a half-migrated estate with both links and a hub and no joining rule
  • Assumes the hub removes the route-entry budget rather than sharing it