What is the first step in designing a network architecture?

Establishing requirements in measurable terms: which systems communicate, at what volume, with what latency tolerance, and what must continue working during a failure. The most useful artefact is a list of required flows with source, destination, and protocol, since every later decision is derived from it.

How should a network be segmented?

By trust level and communication pattern rather than by organisational structure. Systems that communicate constantly and share a blast radius belong together; systems that should never communicate belong apart. Segmenting by department produces boundaries that do not match traffic and degenerate into unmanageable exception lists.

Why does IP address allocation matter so much?

Because it is the hardest decision to change later. Allocating contiguous, summarisable blocks per site and environment keeps routing and filtering expressible in few rules. Overlapping address space surfaces during mergers and partner connections, when it is least fixable, and forces translation that complicates everything after.

What is a failure domain?

The set of components that fail together. It is defined by shared fate rather than by physical proximity, so two links in the same conduit or on the same power feed are one failure domain regardless of appearing as two paths on a diagram. Ask what redundant paths have in common.

How do you keep a network design from drifting?

Record the intended state in a machine-comparable form, covering flows, address allocations, and expected routing, then check reality against it on a schedule. Drift is unavoidable; the goal is detecting it. Generating topology from devices beats maintaining a diagram manually.

How to Design a Network Architecture

Designing a network architecture means deciding addressing, segmentation, routing, and failure domains in an order where later choices do not invalidate earlier ones. Address allocation and segmentation boundaries are the most expensive to change later, so they are settled first, from traffic requirements rather than from an org chart.

Decide in dependency order

Requirements first, in measurable terms. What talks to what, at what volume, with what latency tolerance, and what must keep working when a component fails. A design produced without these is a diagram of preferences. The most useful single artefact is a list of flows: source, destination, protocol, and whether the flow is required for the service to function.

Address allocation. Choose ranges with room to grow, allocated so that summarisation is possible: contiguous blocks per site, per environment, and per segment, so routing and filtering can be expressed in a few rules rather than hundreds. Overlapping address space is the single most expensive mistake available, because it surfaces during a merger or a partner connection, when it is least fixable, and it forces translation layers that complicate everything thereafter. Leave deliberate gaps.

Segmentation boundaries. Decide which groups of systems are separated and where the enforcement point sits. This is the decision that determines blast radius for both failures and intrusions, and retrofitting it means readdressing.

Routing and reachability. How traffic moves between segments, what is announced where, and what the default is. Prefer explicit reachability over a flat default, since a flat network with filtering added later never quite gets the filtering.

Redundancy and failure domains. Where the second path is, and what a single failure takes with it.

Management and observability access. How you reach devices when the data path is broken, which is the part most often discovered missing during the first serious outage.

Why segmentation should not follow the org chart

Segmenting by department produces boundaries that do not match traffic, so the rules between them become long lists of exceptions that nobody can reason about, and the boundary stops providing isolation while still providing complexity. Segment instead by trust level and communication pattern: things that talk to each other constantly and share a blast radius belong together; things that should never talk belong apart. Organisational structure changes every couple of years and addressing does not.

The trade-offs you are actually making

Blast radius against complexity. More segments mean smaller failure and intrusion domains, and more rules, more troubleshooting surface, and more places for a misconfiguration to hide. The right number is the smallest that puts a real boundary around each thing you genuinely need to isolate.

Redundancy against fate sharing. Two links are only redundant if they do not share a conduit, a power feed, a supplier, or a control plane. Diagrams show two lines; failures reveal shared fate. Ask what the two paths have in common, not whether there are two.

Centralised inspection against latency and capacity. Funnelling traffic through a single inspection point simplifies policy and creates a bottleneck and a single failure point. Distributed enforcement scales and multiplies the places policy can differ.

Stretched layer 2 against isolation. Extending a broadcast domain across sites makes some applications easy and couples the sites into one failure domain. It is the classic case of an operational convenience that converts two independent failures into one correlated one.

Dynamic routing against predictability. Dynamic protocols converge around failures and can also propagate a mistake quickly, as route leak incidents regularly demonstrate. Static configuration is predictable and does not heal.

Overlay networks against troubleshooting. Encapsulation decouples logical topology from physical, at the cost of every diagnostic now involving two layers, where problems such as path MTU issues appear as intermittent application failures.

Making the design survive contact

Write down the intended state in a form you can compare against. Not only a diagram. The intended flows, the address allocations, and the expected routing, in a format a script can check. Drift is inevitable; detectable drift is the difference between a design and a historical document.

Treat configuration as code, including routing policy. Reviewed, version controlled, and validated before it applies. The route leak postmortems that name automation as the trigger also name pipeline evaluation as the remedy, and routing policy has the same properties as any other configuration.

Design the failure test before you need it. How you will verify that the second path works, and how often. Untested redundancy has a habit of being discovered non-functional at the moment it is required.

Keep out-of-band management genuinely out of band. If reaching the device depends on the network being up, you do not have management access, you have convenient access. This is cheap to arrange in advance and impossible to arrange during an outage.

Plan for the partner connection you have not been asked for yet. Reserved address space and a defined pattern for third-party connectivity costs nothing now. Being asked to connect an acquisition with conflicting addressing and no reserved range costs a project.

Record why, not just what. The next engineer needs the constraint that produced the decision, because the constraint may be gone. Undocumented reasoning gets preserved as superstition, and designs accumulate rules nobody dares remove.

Expect the diagram to be wrong within a quarter. Generate topology from the devices where you can, and reconcile it against the intended state rather than maintaining a drawing by hand.

Frequently asked questions

What is the first step in designing a network architecture?: Establishing requirements in measurable terms: which systems communicate, at what volume, with what latency tolerance, and what must continue working during a failure. The most useful artefact is a list of required flows with source, destination, and protocol, since every later decision is derived from it.
How should a network be segmented?: By trust level and communication pattern rather than by organisational structure. Systems that communicate constantly and share a blast radius belong together; systems that should never communicate belong apart. Segmenting by department produces boundaries that do not match traffic and degenerate into unmanageable exception lists.
Why does IP address allocation matter so much?: Because it is the hardest decision to change later. Allocating contiguous, summarisable blocks per site and environment keeps routing and filtering expressible in few rules. Overlapping address space surfaces during mergers and partner connections, when it is least fixable, and forces translation that complicates everything after.
What is a failure domain?: The set of components that fail together. It is defined by shared fate rather than by physical proximity, so two links in the same conduit or on the same power feed are one failure domain regardless of appearing as two paths on a diagram. Ask what redundant paths have in common.
How do you keep a network design from drifting?: Record the intended state in a machine-comparable form, covering flows, address allocations, and expected routing, then check reality against it on a schedule. Drift is unavoidable; the goal is detecting it. Generating topology from devices beats maintaining a diagram manually.