How Computers Talk: The Networking Basics Every Developer Should Know

Part 1 of 5 in the System Design Series

Imagine you're in Lagos, it's 11 PM, and you're trying to book a last-minute flight. You open a travel app on your phone, type in your destination, and hit search. In less than two seconds, a list of available flights appears on your screen, pulled from servers possibly sitting in a data center thousands of kilometres away.

That two-second moment? It's one of the most underappreciated miracles in modern engineering. Let's break down exactly what just happened.

The Client and the Server

Your phone in that moment is the client, it's the one asking a question. Somewhere else in the world, a machine is always on, always listening, ready to answer that question. That's the server.

This client-server relationship is the backbone of almost every web application you've ever used. Your browser asks, the server answers.

But here's the obvious question: how does your phone even know where to send the request?

IP Addresses and DNS: The Internet's Phone Book

Every device connected to the internet has an IP address, a string of numbers like 142.250.184.46. Think of it as a phone number for your computer. To reach Google, your device needs that number.

But nobody memorises phone numbers anymore, that's what contacts are for. The internet has the same idea. Instead of typing 142.250.184.46, you type google.com. The Domain Name System (DNS) is the contacts list that translates human-readable domain names into the IP addresses machines actually understand.

So when you typed that travel website into your browser, a DNS lookup happened invisibly behind the scenes, your device asked, "What's the IP for this domain?", got an answer, and only then did it reach out to the right server.

Proxies: The Middlemen

Sometimes your request doesn't go directly to the destination. Enter the proxy.

A forward proxy sits on your side, between you and the internet. It hides your real identity. This is what VPNs essentially do: they route your traffic through a proxy so websites see the proxy's IP, not yours.

A reverse proxy sits on the server's side, between the internet and the backend. When you hit a website, you might actually be talking to a reverse proxy (like Nginx) that decides which backend server should handle your request. From your perspective, it all looks like one system. On the inside, it's a whole orchestra.

Latency: The Cost of Distance

Here's something nobody tells you when you first learn web development: the speed of light is slow enough to matter.

A request from Lagos to a server in London takes roughly 80–120ms just in travel time, the roundtrip delay from physical distance. This is called latency. It's why companies like Netflix and Cloudflare don't just have one server, they have hundreds of servers spread across the globe to be physically closer to their users.

For your travel app, that 11 PM search returning in 2 seconds? Latency is one of the many reasons that felt like magic.

HTTP, HTTPS, and APIs

Your browser and the server speak a shared language called HTTP (HyperText Transfer Protocol). It defines how requests are formatted and how responses are returned. The secure version, HTTPS, wraps everything in encryption, so even if someone intercepts your request mid-flight, they can't read it.

This matters more than most people realise. On public Wi-Fi, unencrypted HTTP traffic can be read by anyone on the same network. HTTPS is why your banking app doesn't expose your account details to the guy next to you at a café.

Now, once your request reaches the server, how does the server know what data to actually return?

That's what APIs (Application Programming Interfaces) are for. An API is a contract: "Send me a request in this format, and I'll send you data back in this format." The travel app on your phone doesn't have a copy of every airline's database, it talks to APIs that do.

APIs return data (usually JSON, a clean, readable format) in a few common styles:

  • REST, The most widely used approach. Stateless, predictable, built on standard HTTP methods like GET, POST, PUT, and DELETE. You ask for a resource, you get it.
  • GraphQL, A more flexible alternative. Instead of getting a fixed bundle of data, you ask for exactly what you need in a single query. No over-fetching, no under-fetching.

Putting It All Together

Go back to that 11 PM flight search. Here's the real story:

  • You type the URL → your device asks DNS for the IP address
  • DNS responds → your device knows where to go
  • Your request travels to a reverse proxy → it routes you to the right server
  • The server receives your HTTPS-encrypted request
  • It calls airline APIs to fetch available flights
  • The data comes back as JSON, your app renders it on screen

    • All of that, in under two seconds.

    Understanding this flow isn't just trivia, it's the foundation every other system design concept is built on. In Part 2, we'll look at what happens when that server can no longer handle the demand on its own.

    Next: Part 2 → Preparing for Traffic: Scaling Your Infrastructure