Designing Efficient Networked Systems: Planning for Scale

Alex: Today we're thinking about how to design a networked system properly. Sam, what does the design process look like for a new network?

Sam: It starts with gathering requirements. Before you draw a single diagram or specify any equipment, you need to understand what the network is for, how many users and devices it needs to support, what applications will run on it, what the availability requirements are, what the security requirements are, and what the budget is. All of these shape every subsequent design decision.

Alex: What are the key technical factors that drive the design?

Sam: Bandwidth is the first one. Different types of traffic have very different bandwidth requirements. High-definition video conferencing, for example, needs significantly more bandwidth than email. You need to size your network links so they can handle peak loads without degrading performance. Then there's latency, which is the delay in transmitting data from one point to another. Applications like voice over IP are very sensitive to latency; even a small delay makes calls sound choppy.

Alex: What about resilience? How do you design for that?

Sam: Resilience is achieved through redundancy. You design multiple paths between critical points so that if one link or device fails, traffic can automatically route around the failure. This means duplicate switches and routers in the core of the network, duplicate uplinks between floors or buildings, and duplicate connections to the internet from different service providers. For highly critical systems, you might even have geographically separate data centres that can take over if one site goes offline.

Alex: Subnetting comes into network design, doesn't it? Can you explain what that involves?

Sam: Subnetting is dividing a network's IP address space into smaller logical segments. Rather than having all your devices in one big network, you split them into subnets based on function, location, or security requirements. The finance team's computers might be on a different subnet from the warehouse devices. This improves security, because you can control which subnets can communicate with each other, and reduces broadcast traffic, because broadcasts only reach devices on the same subnet.

Alex: What about Quality of Service?

Sam: QoS allows you to prioritise certain types of traffic over others. You might configure your network to give voice over IP traffic the highest priority, followed by video conferencing, followed by general business applications, with low-priority traffic like software updates handled in whatever bandwidth remains. This ensures that critical, time-sensitive traffic is never delayed by less important data.

Alex: And documentation? I imagine that's important in design too.

Sam: Essential. A network design should always be accompanied by clear documentation including logical diagrams showing the IP addressing scheme and how subnets are connected, physical diagrams showing where equipment is physically located, and configuration documents describing how each device is set up. Good documentation is what allows the network to be managed, troubleshot, and handed over to a new team member.

Alex: Design before you build. That really is the lesson.

Sam: It's the lesson in almost every area of computing. Time spent designing well saves far more time in implementation and maintenance than the investment costs.

Alex: Brilliant. Thanks Sam. Next we're looking at actually implementing a network.