The Internet, Databases, APIs, and the Cloud: How Modern Systems Are Built

By Pritesh Yadav June 22, 2026 18 min read —

In the foundations chapter you met the machine: how it stores everything as bits, how the CPU follows instructions, how software is just very precise recipes. That gave you one computer doing one job. But the apps you actually use — your bank, a map, a streaming service, the store this very platform runs — are never one computer. They are many computers, often in different countries, talking to each other every second.

This chapter explains how those modern systems are built. We follow the data: from your finger tapping a screen, across the internet, into a database that remembers things, through APIs that let programs cooperate, and onto the cloud where most of it actually runs. By the end you will be able to trace what happens when you press "Enter" in a web browser — step by step — and you will understand the words engineers throw around (server, API, JSON, SQL, container, SaaS) well enough to follow any technical conversation.

Key takeaway: One idea ties this whole chapter together — abstraction: each layer hides the messy details of the layer below it, so you can use a thing without understanding its insides. You use a website without thinking about packets; the website uses a database without thinking about disks. Every section here is one more layer stacked on the last.

23.1 The shape of a modern system

Almost every app you use follows the same basic shape, called the client–server model.

Client: The device in front of you — your phone, laptop, or web browser. It requests things.
Server: An always-on computer somewhere else that provides things: it does the heavy work, stores the data, and sends answers back.

Analogy: A restaurant. You (the client) sit at a table and order from a menu. You never walk into the kitchen. The kitchen (the server) prepares your dish and sends it out. You and the kitchen agree on the menu, and that agreement is the only thing you both need to understand.

This split matters because it lets one server quietly handle thousands of clients at once, and lets the client stay simple. Your phone doesn't store every product in an online shop — it just asks the server, "what products do you have?" and shows whatever comes back.

   CLIENT                        SERVER
 (your phone)                (always-on computer)
     |                              |
     |  ---- "show me products" --->|
     |                              |  (looks in database)
     |  <--- list of products ------|
     |                              |
   shows them                     waits for
   on screen                   the next request

Now we need to explain how that request actually travels from your phone to a server that might be 8,000 km away — and back — in a fraction of a second. That is the internet.

23.2 How the internet actually works

A network is just computers connected so they can share data. The internet is the global "network of networks" — millions of local networks linked together.

Analogy: The roads. Your street is a small local network. The internet is the entire global road system — local streets, highways, and international shipping lanes — all connected so a package can get from any door to any other door.

Every device needs an address: the IP address

For data to find the right computer, every device on a network has a unique numeric address called an IP address (Internet Protocol address) — for example 142.250.72.14.

Analogy: An IP address is a postal address for a computer. Without it, the mail has nowhere to go.

The old format (IPv4) has about 4 billion addresses, and the world ran out of them — so a much larger newer format (IPv6) exists to give every device its own address.

Humans use names, not numbers: DNS

You don't type 142.250.72.14; you type google.com. Something has to translate the human name into the numeric address. That something is DNS (the Domain Name System).

Analogy: DNS is the contacts app on your phone. You remember "Mom," not her ten-digit number. You tap the name, and your phone looks up and dials the real number behind the scenes.

Data travels in packets

When you send something over the internet, it is not sent as one big lump. It is chopped into small labeled chunks called packets. Each packet finds its own way across the network, and they are reassembled in the correct order at the destination.

Analogy: You want to mail a 300-page book. Instead of one heavy parcel, you tear it into numbered pages and send each page as a separate postcard. Each postcard may take a different route. At the other end, the pages are sorted back into order. If page 47 gets lost, you just ask for that one page again — not the whole book.

The rule set: TCP/IP

For all of this to work, every computer must agree on the same rules. That shared rule set is TCP/IP, and it has two main jobs:

IP handles addressing and routing — getting each packet pointed toward the right destination (like the postal system's addresses and sorting hubs).
TCP guarantees reliability — it confirms every packet arrived, in the right order, and re-sends any that got lost (like certified mail with delivery confirmation).

There is a faster, looser cousin called UDP that sends packets without tracking or re-sending — like dropping postcards in a mailbox and hoping they arrive. It's used for live video calls and online games, where a single missed frame doesn't matter and waiting for a re-send would cause worse lag.

The web's language: HTTP and HTTPS

HTTP (HyperText Transfer Protocol) is the language browsers and web servers use to ask for and send pages and data. HTTPS is the same thing, but encrypted — the padlock you see in the address bar.

Analogy: HTTP is the standard back-and-forth script between you and the restaurant kitchen ("I'd like X" → "here is X"). HTTPS is having that exact conversation inside a sealed, tamper-proof envelope so no one in between can read or change it.

Common mistake: Believing the HTTPS padlock means a site is "safe" or "legitimate." It only means the connection is encrypted — nobody can eavesdrop between you and the site. It says nothing about whether the site itself is honest. Scam and phishing sites can and do have padlocks too.

Putting it together: the request lifecycle

This is the single most useful thing to understand in this chapter. Here is exactly what happens when you type a web address and hit Enter:

You type the URL (e.g. shop.example.com).
DNS lookup: your browser asks DNS, "what's the IP address for that name?" and gets back a number.
TCP connection: your browser and the server do a quick "three-way handshake" (a hello, a hello-back, and a confirm) to open a reliable connection.
HTTPS encryption setup: the two sides agree on a secret key so the conversation is private.
HTTP request: your browser sends "GET me the home page."
Server responds with the page's ingredients: HTML (the content), CSS (the styling), and JavaScript (the interactive behavior).
Browser renders all of that into the page you see.

Analogy: You look up a restaurant's address (DNS), walk in and get seated and verified (TCP + HTTPS), place your order (HTTP request), the food arrives (response), and you assemble your plate (the browser renders the page). All of it happens in well under a second, every time you open any page.

Example: When you open a maps app, this whole lifecycle runs several times — once for the page, again to fetch your location's map tiles, again to fetch directions. Every payment, every message, every search you've ever done is this loop running invisibly.

Common mistake: "I have fast internet, so everything should feel instant." Speed has two parts: bandwidth (how much data per second — the width of the pipe) and latency (the delay before data starts arriving — the lag). A request to a server far away has to make a physical round-trip; distance and the number of back-and-forth trips (latency) often matter more than raw bandwidth. A huge download with a fat pipe can still feel sluggish to start if the server is far.

23.3 Databases: how systems remember

A server can send you a page — but where does it get the data? When a shop "remembers" your past orders, or your bank knows your balance, that information lives in a database.

Database: An organized system for storing, retrieving, and updating large amounts of data reliably — and letting many people use it at once without overwriting each other.

Analogy: A giant, smart, multi-user spreadsheet. An ordinary spreadsheet breaks if two people edit it at once. A database is built so thousands of people can read and change it safely at the same time, and it won't lose or corrupt the data if the power blips.

Two big families: SQL and NoSQL

SQL (relational)	NoSQL
Data lives in linked tables of rows and columns.	Data lives in flexible documents or key–value pairs.
Strict structure: every row has the same columns.	Flexible: each record can hold different fields.
Best when data is structured and relationships matter (orders linked to customers).	Best when data is varied or changing shape rapidly.
Like: a strict accounting ledger with fixed columns.	Like: a box of index cards, each can say something different.

"SQL" (Structured Query Language) is also the name of the language you use to talk to relational databases. The whole relational idea comes from Edgar F. Codd, who invented the model in 1970.

Querying

A query is simply a request to the database to fetch or change specific data.

Analogy: Asking a librarian, "give me every book by this author published after 2020." You describe what you want; the database goes and finds exactly those records.

One advanced idea worth naming: in big systems spread across many machines, the CAP theorem says a distributed database can fully guarantee only two of three things at once — Consistency (everyone sees the same data), Availability (it always answers), and Partition-tolerance (it keeps working even if the network between machines breaks). Engineers must choose which to favor. You don't need the math — just know the trade-off exists.

Example: A store's database holds tables like customers, products, and orders. When you place an order, a row is added to orders that links to your row in customers and the product rows you bought. That linking is what "relational" means — and it's how the system later answers "what did this customer buy last month?"

23.4 APIs: how programs talk to each other

So far one client talks to one server, and that server reads one database. But modern products are rarely built from scratch. "Log in with Google," an embedded map, a Stripe payment box, live shipping rates — each is another company's software being used through a doorway called an API.

API (Application Programming Interface): A defined, agreed-upon way for one program to request services or data from another.

Analogy: A restaurant menu. The menu is a fixed list of things you're allowed to order, described in a way both sides understand. You don't walk into the kitchen and rummage around — you ask through the menu and get a predictable result. An API is a program's menu: "here are the exact requests you may make, and here's what you'll get back."

This is arguably the most important integration concept in modern software. Most apps you use are assemblies of other companies' APIs stitched together.

REST and JSON: the common style and format

Most web APIs follow a style called REST, which uses predictable web addresses for each kind of data (e.g. asking /orders/123 to get order number 123). The data itself is usually sent as JSON — a human-readable text format.

A JSON response for one product:

  {
    "name": "Business Cards",
    "price": 19.99,
    "in_stock": true
  }

Analogy: JSON is a clearly labeled form that both sides agree to fill out — "name: ___, price: ___, in stock: ___." Because the labels are fixed and the format is plain text, any program in any language can read it.

Example: When an online store shows you a delivery cost, it often sends your address to a shipping company's API and gets back a JSON answer like {"price": 6.50, "days": 3}. The store never knows the shipper's internal systems — it just uses the menu. That is how a small team can offer payments, maps, login, email, and shipping without building any of them.

Common mistake: If a form sends a field but the receiving program never accepts it, the data is silently dropped — the user sees "Saved" but the value is gone. Whenever programs exchange data, every field must round-trip: validate it, save it, read it back, and show it. A field that is collected but never stored is one of the most damaging and common bugs in real software.

23.5 The cloud: renting computers instead of owning them

All these servers and databases run on real, physical machines. Twenty years ago, you bought those machines and kept them in a room with loud fans and cold air. Today most companies rent them over the internet. That is the cloud.

The cloud: Renting computing power, storage, and software over the internet from a provider (like Amazon Web Services, Google Cloud, or Microsoft Azure) instead of owning the hardware yourself.

Analogy: Electricity. You don't own a power plant; you plug into the grid and pay for what you use, and someone else maintains the plant. The cloud is computing from the grid.

Common mistake: Thinking the cloud is "somewhere ethereal," floating and weightless. It isn't. The cloud is simply someone else's computers sitting in giant warehouse-sized buildings called data centers, full of real machines and real cables. No magic — just rented hardware you reach over the internet.

What makes the cloud possible: virtualization and containers

Virtualization uses software to split one powerful physical computer into several independent "virtual" computers (virtual machines), each acting like its own separate machine.

Analogy: Dividing one big warehouse into many separately-locked rented units. One building, many tenants who can't see into each other's space. This is the foundation of the entire cloud business — it lets a provider rent slices of one machine to many customers.

A lighter, more modern version is the container (the best-known tool is Docker). A container packages an app together with everything it needs to run, so it behaves identically on any machine. Managing thousands of containers automatically is done by orchestration (the best-known tool is Kubernetes).

Analogy: A shipping container. Standardized steel boxes mean any crane, ship, or truck can handle any container the same way, anywhere in the world. Kubernetes is the automated port — the crane system coordinating thousands of containers without a human placing each one.

The three service levels: IaaS, PaaS, SaaS

Cloud services differ by how much the provider manages for you. The classic way to teach this is "pizza as a service":

Level	You manage	Pizza analogy	Example
IaaS (Infrastructure)	The operating system and your apps; they give you raw servers, storage, network.	They give you the kitchen; you make the pizza.	AWS EC2
PaaS (Platform)	Just your app's code; they handle the servers and platform.	They give you the kitchen plus dough and oven; you add toppings.	Heroku, Google App Engine
SaaS (Software)	Nothing technical — you just use the finished app in a browser.	Pizza delivered; you just eat.	Gmail, Salesforce

Example: The print-store platform that runs many shops at once is itself a SaaS product — store owners just log in and use it through a browser. Behind the scenes it likely rents IaaS/PaaS resources to run on. SaaS is built on top of the lower tiers.

Serverless: pay only when something runs

A newer model is serverless (also called Functions-as-a-Service, e.g. AWS Lambda). You upload a piece of code; it runs only when something triggers it; the provider handles all the servers and scaling; and you pay per execution — nothing while it sits idle.

Analogy: A motion-sensor light. It costs nothing while the room is empty, then snaps on the instant someone walks in. (The name is misleading — there are still servers; you just never see or manage them.)

Handling lots of users: scaling and load balancing

Scalability is the ability to handle more users by adding capacity. A load balancer spreads incoming traffic across many servers so no single one is overwhelmed. Adding capacity comes in two flavors:

Vertical scaling — a bigger, more powerful single machine.
Horizontal scaling — more machines working together (usually preferred at scale).

Analogy: A supermarket at rush hour. Vertical scaling is making one cashier faster; horizontal scaling is opening more checkout lanes. The load balancer is the greeter directing each shopper to the shortest line.

Key takeaway: The cloud is why a single person can launch a product that scales to millions. You rent Google-scale infrastructure for cents, pay only as you grow, and let the provider handle the machines. No server room, no upfront fortune — this is literally why modern SaaS startups can exist.

23.6 A worked end-to-end example

Let's connect everything. You open an online print shop on your phone and view a product. Here is the full journey, top to bottom:

1. You tap the link  →  DNS turns "shop.com" into an IP address
2. Phone opens a reliable TCP+HTTPS connection to the server
3. Phone sends HTTP request: "GET the product page"
4. Server runs its code (backend logic)
5. Server QUERIES the database: "fetch product #123"
6. Server may call an external API (e.g. shipping price)
7. Server packages it all as JSON / HTML and sends it back
8. Your browser RENDERS the page; you see the product
   — and the server, database, and APIs all run in the CLOUD

Every layer here is an abstraction hiding the one below: you don't think about packets, the website doesn't think about disk platters, the cloud customer doesn't think about which physical machine they're on. That stacking of hidden complexity is what lets a small team build something enormous.

Common mistake: Assuming abstractions never leak. They do. When something breaks badly — a slow page, a mysterious error — the layer below always resurfaces. The page is slow? Maybe the database query is inefficient, or the network latency is high. The competent person knows their layer; the expert stays curious about the layer beneath it, because that's where hard problems hide.

23.7 Best practices for understanding (and building) modern systems

Best practice: Learn the request lifecycle cold (section 23.2). It is the backbone of nearly every system you'll ever use or build. If you can narrate "DNS → TCP → HTTPS → HTTP → server → database → response," you can reason about almost any web problem — including why something is broken or slow.

Best practice: Think in terms of "where does the data live and who owns it?" Client, server, database, or someone else's API. Most confusion in modern systems disappears once you can point to where a piece of data actually sits and which program is allowed to change it.

Best practice: When using an API, treat it like a contract. Read what it expects, what it returns, and what happens when it fails. The hardest bugs in connected systems are not when an API works — they're when it returns nothing, returns slowly, or returns an error you didn't plan for.

23.8 Chapter summary

Modern systems are not one clever computer. They are layers of cooperating machines, each hiding complexity from the one above:

Client–server: your device asks; an always-on server answers.
The internet: data is addressed (IP), named for humans (DNS), chopped into packets, and delivered reliably (TCP/IP) using the web's language (HTTP/HTTPS).
Databases are how systems remember — organized, multi-user, reliable stores, queried for exactly what's needed.
APIs are the menus that let programs use each other's services, usually exchanging plain-text JSON. They run the modern software economy.
The cloud is renting real computers over the internet — split up by virtualization and containers, offered as IaaS/PaaS/SaaS or serverless, and scaled with load balancers.

Key takeaway: Every modern app is a stack of abstractions over the same few ideas — a request travels the internet to a server, which reads a database and maybe calls an API, all running on rented cloud machines. Understand that single sentence deeply and the entire technology landscape stops feeling like magic and starts looking like plumbing you can follow.

Continue reading

🧭 Ten Disciplines

Seeing the Whole: What a System Is and Why It Behaves the Way It Does

🧭 Ten Disciplines

The Machinery of Systems: Stocks, Flows, Feedback Loops, and Delays

🧭 Ten Disciplines

Leverage Points, System Traps, and Thinking in Systems (Advanced & Real-World)