Search for a command to run...
Modems, routers, switches, and load balancers. A developer’s guide to the physical network devices that make the internet possible.
No comments yet. Be the first to comment.
These are the assignments or knowledge dumps I decide to write for the "Chai aur Code's web Dev Cohort 2026"
How the Transmission Control Protocol guarantees that your data arrives intact, in order, and without errors across a chaotic internet.
RAG helps LLMs answer questions using your own data, but it doesn't guarantee correct answers. Here's how the pipeline works and where it commonly breaks down.
Imagine asking an AI, "Write a blog," versus "Act as an SEO expert and write a 1,000-word blog on AI safety formatted in markdown." The difference in the resulting output is night and day. A prompt is
Spotify and Apple Music make it incredibly easy to showcase your live listening habits on your website. YouTube Music? Not so much. After doing some setup you can do an API call and fetch your account
Arthur C. Clarke's famous third law: "Any sufficiently advanced technology is indistinguishable from magic" perfectly captures how the pace of human innovation works. From carrying supercomputers in o
Why HTTP is amnesiac, the difference between transport and state, and how to choose the right auth strategy for your Node.js app.
We write an API, deploy it to "the cloud," and trust that when a user types a URL, HTTP requests will just magically find their way to our servers.
But the cloud is not an abstract entity. The cloud is a loud, cold warehouse filled with miles of fiber-optic cables and thousands of blinking hardware devices.
When you build distributed systems, virtual private clouds (VPCs), or microservices, the software abstractions you use are directly modeled after physical networking hardware. If you don't know how a switch differs from a router, configuring a cloud network will feel like guesswork.
To bridge the gap between software and infrastructure, we need to step away from code for a moment and look at the physical boxes that actually move our bytes. Let’s trace the journey of a network packet from the outside world all the way to a production server, looking at the hardware it hits along the way.
When an Internet Service Provider (ISP) runs a cable to a building, the signal traveling through that wire is not something a computer can understand. If it is a copper coaxial cable, it carries analog radio frequencies. If it is a fiber-optic cable, it carries pulses of light.
Your computer, however, only understands digital signals—ones and zeros.
The modem (short for Modulator-Demodulator) sits at the very edge of your network. Its single job is translation. It takes the analog or optical signal from the outside world and demodulates it into a digital ethernet signal. When you send data out, it modulates your digital data back into a format that can travel miles down the street.
If your network is an island, the modem is the ferry terminal. Without it, you cannot cross the ocean to the rest of the internet.
A modem gives you an internet connection, but it only gives you one public IP address. If you plug a laptop directly into a modem, that laptop is on the internet. But what about your phone? What about your smart TV?
This is where the router comes in.
A router's job is to connect two different networks together. Specifically, it connects your Local Area Network (LAN) to the Wide Area Network (WAN—the internet).
The router acts as the dispatcher. It assigns a private, internal IP address (like 192.168.1.5) to every device in your building. When your laptop requests a web page, the request goes to the router. The router remembers that your laptop asked for this data, stamps the request with its single public IP address, and sends it out to the internet. When the web page data comes back, the router looks at its internal ledger, realizes the data is for your laptop, and routes it to the correct internal IP.
(The Internet)
|
[ Modem ]
| <-- Public IP: 203.0.113.5
[ Router ]
/ \ <-- Private IPs
[Laptop] [Phone]
192.168.1.2 192.168.1.3
A router manages the borders, but how do internal devices actually physically connect to each other? If you have an office with fifty desktop computers, they don't all plug directly into the router. They plug into a switch.
A switch connects devices within the same network.
To understand why switches are brilliant, you have to understand the outdated hardware they replaced: the hub.
A hub is basically a dumb electrical splitter. If a packet comes into a hub destined for Computer A, the hub doesn't know where Computer A is. So, it simply duplicates the packet and blasts it out to every single computer plugged into it. This causes massive network congestion and security issues.
A switch is a smart hub. It memorizes the physical hardware address (MAC address) of every device plugged into its ports. When a packet arrives for Computer A, the switch looks at its internal table, finds the exact port Computer A is plugged into, and sends the packet only down that specific wire.
[ Hub vs Switch Behavior ]
HUB (The Dumb Megaphone)
Packet for A arrives -> Blasts to A, B, C, and D.
Result: Collisions, slow network.
SWITCH (The Smart Postman)
Packet for A arrives -> Checks MAC table -> Sends ONLY to A.
Result: Fast, isolated, secure traffic.
As traffic moves into your network, you need a way to ensure it isn't malicious.
A firewall is a security device that monitors and controls incoming and outgoing network traffic based on predetermined security rules. It acts as a barrier between a trusted network (your servers) and an untrusted network (the internet).
Imagine a firewall as a security guard at an office building. The guard has a list of rules:
Rule 1: Anyone can enter through the front door (Port 80/443 for web traffic).
Rule 2: Only employees with special badges can enter the maintenance room (Port 22 for SSH access).
Rule 3: Block anyone arriving from a known list of malicious addresses.
In modern infrastructure, firewalls drop bad packets before they ever reach your application code. If you try to query a database from an unauthorized IP address, the firewall simply ignores the request. The database never even knows you knocked.
If you run a small website, pointing your router straight to a single server works fine. But what happens when you have 100,000 users trying to check out on Black Friday? A single server will melt under the CPU load.
You need ten servers. But you only have one domain name (yourstore.com). How do you split the traffic?
You place a load balancer in front of them.
A load balancer is a device (or software running on a device) that acts as a reverse proxy. It receives all incoming internet traffic, looks at the health and current workload of your backend servers, and intelligently distributes the requests across them.
If Server 3 crashes, the load balancer instantly stops sending traffic to it and reroutes those requests to the remaining healthy servers. To the end user, the application never goes down.
When you type a URL to access a large web application, your request travels through this exact chain of hardware:
(Your Browser)
|
[ The Internet ]
|
[ Modem ] <-- Demodulates signal into digital data
|
[ Edge Router ] <-- Routes packet into the company's network
|
[ Firewall ] <-- Inspects packet; allows Port 443 (HTTPS)
|
[ Load Balancer ] <-- Picks the least-busy server
/ | \[ Switch ] <-- Forwards packet to the exact server port
| | |[S1] [S2] [S3] <-- Your backend application servers
Why does this hardware lesson matter to a software engineer?
Because when you deploy to AWS, GCP, or Azure, you have to configure these exact components in software.
When you set up an Internet Gateway in AWS, you are configuring a virtual Modem/Router.
When you set up a VPC Subnet, you are configuring a virtual Switch.
When you write Security Groups, you are configuring a Firewall.
When you spin up an Application Load Balancer, you are configuring exactly that.
The cloud is just a software wrapper around these physical boxes. Once you understand the hardware, the software stops being a mystery, and you start designing systems that actually make sense.