Network Topologies and Architectures

Picture, for a moment, the street plan of a city you know well. Some cities grew around one great square, with every road eventually leading back to it. Some grew as a grid, endlessly repeatable, block after identical block. Some grew as a tangle of alleys nobody planned on purpose, shaped by centuries of people simply walking the shortest path between two points until the ground itself remembered it. None of those cities are wrong. Each one is the visible result of thousands of small decisions about cost, safety, and convenience, made by people who never met each other, compounding over time into a shape.

Networks have the exact same kind of shape, and engineers have a name for it: topology. A topology is the layout of how devices are wired together — which machine talks directly to which other machine, and which ones only reach each other by going through a third. It sounds like a small, almost cosmetic detail, the kind of thing you could safely ignore in favor of protocols and packets. It is not. The shape of a network quietly decides how it fails, how it scales, how expensive it is to build, and how hard it is to keep an eye on — long before a single packet ever moves across it.

A topology is a bet about which failure you can afford: a single point of failure you accepted to save money, or the extra cost you paid to avoid one.

Bus Topology: The Single Main Street

Imagine a single street with every house's front door opening directly onto it, and no side roads at all. That is a bus topology: every device shares one continuous cable, tapping into the same physical wire the way houses tap into the same street. It was the shape of the earliest Ethernet networks in the 1970s and 1980s, and it was popular for one simple, honest reason — a single length of shared coaxial cable was astonishingly cheap compared to running a dedicated wire to every device individually.

That cheapness came at a brutal price the moment anything went wrong. Cut the street anywhere along its length, and every house on it loses access to everything past the cut — there is no detour, because a detour was never built. Worse, because every device is shouting onto the exact same physical wire, adding more devices does not just add more capacity demand; it adds more chances for two devices to "speak" at the same instant and collide, garbling both messages and forcing both to wait and retry. A bus network does not merely get more crowded as it grows — it gets proportionally slower for everyone, which is a brutal way for a network to behave once a company outgrows a handful of desks.

Bus topology is essentially extinct as a wired design today, but its ghost is very much still with you. Classic Wi-Fi, for all that it looks like a tidy star on a diagram — every device with its own private link to the router — behaves, underneath, exactly like a bus: every device on the same channel is sharing the same slice of radio spectrum, and only one of them can transmit into it at a genuine instant without the others' signals turning into noise. The wiring diagram lied. The physics didn't.

Star Topology: The Plaza Every Road Feeds Into

Now imagine the opposite: a city built around one central plaza, with every road running straight to it and none of them running to each other directly. That is a star topology — every device connects not to its neighbors but to one central point, historically a hub, and in essentially every network built since the 1990s, a switch.

Star topology did not win by being clever; it won by becoming affordable. Once switches dropped in price through the 1990s, the tradeoff that had kept bus networks dominant simply flipped. Paying for one piece of central hardware suddenly looked cheap next to what it bought you: a single bad cable no longer took down an entire building, it took down exactly one desk, because that desk's cable was the only thing connected to it. Adding, removing, or troubleshooting a device became a matter of touching one cable at the plaza, not tracing a wire that ran the length of an entire floor.

Ring Topology: The Circular Subway Line

Some networks were built as a loop instead — imagine a circular subway line where each train only ever moves in one direction, stopping at station after station until it eventually returns to where it started. In a ring topology, each device connects to exactly two neighbors, forming a closed circle, and data travels around it from station to station until it reaches its destination.

The elegant part of a ring is how it avoids the shouting-match problem a bus suffers from: rather than every device competing to speak at once, a small digital "token" circulates continuously around the ring, and only whichever device is currently holding it is allowed to transmit. No collisions, no chaos — just an orderly, if occasionally slow, single-file line. IBM built an entire competing standard around this idea, called Token Ring, which spent years as Ethernet's genuine rival for dominance in corporate networks before Ethernet's falling costs and rising speeds won the argument decisively.

A plain ring shares bus topology's fragility in one specific way — sever the loop at any single point and the ring becomes two dead-end lines instead of one working circle, since a token can no longer complete its lap. Engineers solved this the way city planners solve a subway line with only one track: they built a second one running the opposite direction, so a single break can be healed almost instantly by simply reversing traffic around the intact half. Metropolitan fiber backbones still use exactly this dual-ring, self-healing design today, decades after Token Ring itself faded from the corporate desktop.

Mesh Topology: Everyone Connected to Everyone

Push redundancy to its logical extreme and you get a mesh topology — picture a spiderweb, where instead of one central plaza, every house has its own road running directly to every other house. In a full mesh, every single node has a direct link to every other node; in a partial mesh, only some of those pairs are connected directly, and traffic occasionally makes a short hop through an intermediate node on its way to somewhere else.

The appeal of a mesh is obvious the instant you think about failure: sever any single link, and traffic simply flows around the gap through one of the many alternate paths that already exist. Nothing has to be repaired in an emergency for the network to keep functioning, because redundancy was built in from the start rather than bolted on afterward. The cost is equally obvious once you do the arithmetic. A full mesh of n nodes needs roughly n(n-1)/2 direct links to connect everyone to everyone — ten nodes need forty-five separate links, and a hundred nodes would need nearly five thousand. That number explodes so quickly that a genuine full mesh is only ever practical for a small handful of critical nodes; everything past that scale has to fall back to a partial mesh instead.

Hybrid Topology: The City as It Actually Gets Built

No real city is purely a grid, purely a plaza-and-spokes design, or purely a tangle of alleys — it is whatever combination of all three that decades of growth and compromise produced. Networks end up the same way. A hybrid topology simply names the honest reality that most networks past a certain size stop being one pure shape and become a deliberate combination: a company might wire each floor of an office as its own star radiating from a floor switch, then connect those floor switches to each other in a partial mesh so no single floor's failure isolates the rest of the building. Pure, single-topology networks are the exception in the real world, not the rule — hybrid is not a fifth category so much as an acknowledgment that the other four are ingredients, not finished designs.

Physical Shape Versus the Shape Data Actually Takes

Here is a distinction worth sitting with, because it explains a great deal of otherwise confusing behavior in real networks: the wires you could physically trace by hand are not necessarily the path data actually follows. The wiring diagram is called the physical topology; the pattern data actually flows in is the logical topology, and the two can, and often do, disagree.

Wi-Fi is the cleanest possible example, and it already came up twice in this chapter for good reason. Physically, every device has its own private point-to-point radio link to the router — a textbook star, no different in shape from wired Ethernet. Logically, though, every one of those devices is sharing the same slice of airwaves, so only one can transmit at a genuine instant without garbling the others — a textbook bus, in behavior if not in wiring. A wired office tells a similar story in the other direction: it might be physically a pure star, every desk cabled back to one closet full of switches, while logically behaving like a partial mesh at the switching level, since switches learn where devices actually live and forward traffic accordingly rather than blindly following the wiring diagram.

Architectures: Not the Shape, but Who Plays Which Role

Topology answers "what is the wiring shape." A completely separate question is architecture: once the wiring exists, what role does each device play in a given conversation? The two ideas are independent of each other — you can run a client-server system over a star (the overwhelmingly common case) or, in principle, over a mesh; the wiring shape does not dictate who is allowed to ask for what.

In a client-server architecture, picture a restaurant: customers (clients) place an order, and a kitchen (the server) prepares and delivers it, while the customers never cook for each other. This is the architecture behind the overwhelming majority of everyday internet services — every website you have ever visited, every email you have ever sent, every database behind every app you have ever opened. Centralizing control this way makes a system dramatically easier to secure and manage, since there is only one kitchen to lock the door on, but it also means that kitchen is both a single point of failure and, at large enough scale, a bottleneck that has to be provisioned for the busiest moment of the year, not the average one.

In a peer-to-peer architecture, picture a potluck dinner instead: everyone brings a dish, everyone shares, and there is no central chef anyone is depending on. BitTorrent popularized this shape for file sharing, and blockchain networks lean on it for a related reason — no single computer is the definitive authority, so there is no one server whose failure, or whose owner's decision, can take the whole system down. The tradeoff flips accordingly: a peer-to-peer system scales naturally, since each new participant typically brings capacity as well as demand, but it is much harder to secure, because there is no single administrator vouching for anyone, and trusting a message from an arbitrary stranger-peer is inherently riskier than trusting a server whose operator you already know.

The Same Tradeoffs, Everywhere You Look

Step back and both halves of this chapter turn out to be telling the same story from two different angles. A bus is cheap and fragile; a mesh is resilient and expensive; a star traded a single point of failure for manageability and mostly won the argument for thirty straight years. A client-server system is easy to lock down and easy to overwhelm; a peer-to-peer system is nearly impossible to take down and nearly impossible to fully police. There is no topology and no architecture that is simply "the best one" in the abstract — there is only the one that matches what you can afford to lose, what you can afford to build, and how much you need the thing to survive a bad day.

Modern data centers make this concrete at a scale most people never see: many now run a "leaf-spine" design, a two-layer, deliberately mesh-like hybrid built specifically to guarantee that any server can reach any other server in a small, predictable number of hops, no matter how large the data center grows. It is, quite literally, the star-versus-mesh tradeoff from earlier in this chapter, engineered by people who needed both the manageability of a star and the resilience of a mesh at the same time, and refused to fully give up either one.

Bus:   [A]---[B]---[C]---[D]
Star:      [B]
         / | \
      [A][C][D]
Ring:  [A]---[B]
         |     |
       [D]---[C]
Mesh:  [A]---[B]
         | X |
       [D]---[C]

The next time you glance at a network diagram in the wild — an office floor plan, a data center rack layout, a cloud provider's architecture guide — try naming its shape before reading the label. Is it leaning on one plaza everything depends on? Redundant paths that cost real money to build? A single shared street everyone crowds onto? That instinct, more than any diagram in this chapter, is what carries forward into every networked system you will eventually design yourself, starting with the very first Go program you write in the part of this book that follows.

Frequently Asked Questions

If Wi-Fi looks like a star on every diagram, why does this chapter keep calling it a bus? Because a diagram only ever shows the physical topology — the wires, or in this case the individual radio links between each device and the router — and that is not the same thing as the logical topology, which is the pattern the data actually behaves in. Every laptop and phone on a Wi-Fi network does have its own private-looking link to the router, but they are all shouting into the same shared slice of airwaves, so only one can transmit at a genuine instant without garbling the others. The wiring diagram is technically honest and practically misleading at the same time, which is exactly the kind of gap this chapter wants you to learn to notice.

Is the internet really a mesh network, then? Yes, but a partial one, and that distinction matters enormously. A full mesh needs roughly n(n-1)/2 direct links to connect everyone to everyone, a number that explodes so fast it becomes physically impossible past a small handful of nodes — a hundred routers would already need nearly five thousand direct links. The internet instead relies on enough redundant paths between major points that traffic can usually route around any single failure, without any router needing a direct line to every router it might eventually need to reach.

Why did star topology beat bus and ring if a hub or switch is still a single point of failure? Because "one bad cable takes down one desk" turned out to be worth far more than the theoretical risk of the central switch dying, especially once switches became cheap enough in the 1990s to make that trade affordable. Engineers did not ignore the weakness — they built around it with redundant switches, backup power, and failover links — but a single central risk you can actively defend is a much better bet than a shared cable where any cut anywhere kills everything past it.

Does the wiring shape of a network decide whether it's client-server or peer-to-peer? No, and that surprises a lot of people the first time they hear it. Topology answers "what is the wiring shape," while architecture answers "what role does each device play in a conversation," and the two are independent — a client-server system overwhelmingly runs over a star-shaped network, but nothing about a star forces that choice, and a peer-to-peer system like BitTorrent can happily run over the exact same physical wiring.

What's actually different about a "hybrid" topology versus just calling something a mesh? A hybrid isn't a fifth shape competing with the other four so much as an admission that real networks rarely stay pure past a certain size. A company might wire each floor as its own star radiating from a floor switch, then connect those floor switches together in a partial mesh — which is neither a textbook star nor a textbook mesh, but a deliberate combination of both, chosen because different parts of the same network face different failure and cost tradeoffs.

Fun Facts and Notes

• The first network topologies were sketched on napkins and whiteboards by engineers in the 1970s designing the earliest LANs, long before any of these shapes had settled into the standard diagrams you see in textbooks today.
• The internet is often described as the world's largest partial mesh network — a single packet can typically travel dozens of genuinely different routes to reach the same destination, and usually does not take the same one twice in a row.
• Token Ring, IBM's ring-shaped rival to Ethernet, was for a time the more technically elegant option — no collisions, predictable performance — and lost anyway, a reminder that the cheaper, messier technology sometimes wins simply by getting cheap faster.