Networking
Before any application logic runs, two machines have to find each other, agree to talk, and — usually — agree to keep the conversation private. This is the plumbing underneath every request.
What an IP address is
An IP address is a numeric label assigned to a device on a network, so other devices know where to send data. Every server you talk to on the internet has one.
- IPv4 Four numbers 0–255, e.g.
142.250.72.14. ~4.3 billion possible addresses — running out. - IPv6 A longer format, e.g.
2607:f8b0::14. Built to never run out.
Domain Name System
Humans use names like example.com; machines route by IP address. DNS is the lookup system that translates one into the other before a connection can even start.
- Step 1 Browser checks its own cache — has it looked this up recently?
- Step 2 If not, it asks a resolver (often your ISP or a public one like
1.1.1.1). - Step 3 The resolver walks a hierarchy — root →
.comregistry → the domain's own nameserver — until it gets an answer.
Establishing a reliable connection
Once the browser has an IP address, it can't just start firing data at it. TCP (Transmission Control Protocol) first opens a reliable, ordered connection with a three-step handshake — a bit like confirming both sides are on the line before you start talking.
What TLS adds on top
TCP gets two machines talking, but that channel is plain text by default — anyone between you and the server could read or tamper with it. If the URL starts with https://, a TLS handshake runs immediately after the TCP handshake to fix that.
Certificate check
The server presents a certificate, signed by a trusted Certificate Authority, proving it's really who the domain claims it is.
Key exchange
Browser and server agree on a shared secret key, without ever sending that key in the open.
Encrypted from here
Every request and response after this point is encrypted with that key — confidentiality, integrity, and authentication in one pass.
URL → Render Lifecycle
Everything from Sheet 01, plus the application layer, chained into one trip. Step through what actually happens between hitting Enter and seeing pixels.
Parse URL
—
HTTP Essentials
HyperText Transfer Protocol is the language browsers and servers speak once a connection is open. It's stateless — every request stands alone, with no memory of the last one — and structured as a request followed by a response.
What you're allowed to say
| Method | Typical use |
|---|---|
GET | Retrieve a resource. Safe — shouldn't change anything. |
POST | Create a resource, or submit data / trigger an action. |
PUT | Replace a resource entirely. |
PATCH | Update part of a resource. |
DELETE | Remove a resource. |
GET, PUT, and DELETE give the same end state no matter how many times you repeat them. POST usually doesn't — run it twice, get two orders.Request & response, side by side
Request
- Line
GET /pricing HTTP/1.1 - Headers
Host,Accept,User-Agent,Cookie - BodyPresent on
POST/PUT/PATCH, e.g. a JSON payload
Response
- Line
HTTP/1.1 200 OK - Headers
Content-Type,Set-Cookie,Cache-Control - BodyThe actual payload — HTML, JSON, an image, etc.
What the server is telling you
Every response starts with a three-digit status code. The first digit tells you the category before you even read the rest.
Backend Architecture
Once a request arrives, it usually isn't handled by one lone machine. It passes through a small chain of responsibility built for reliability and scale.
From client to data, and back
The load balancer is the front door — it distributes incoming requests across several identical app server instances, so no single machine gets overwhelmed and traffic keeps flowing if one instance goes down.
Where your code runs
This is the layer engineers spend most of their time writing: routing a request to the right handler, running business logic, talking to the database, and shaping a response.
/users/42), and the HTTP method says what to do with them. Consistency over cleverness.Avoiding repeat work
- BrowserStores static assets locally so they aren't re-downloaded.
- CDNServes assets from a server geographically close to the user.
- In-memoryTools like Redis keep hot data in RAM, far faster than a database round trip.
Handling more traffic
Vertical
Give the existing machine more CPU/RAM. Simple, but there's a ceiling — and a single point of failure.
Horizontal
Add more machines behind a load balancer. Scales further, and if one instance fails, the rest keep serving.
Database
Requests come and go, but state has to live somewhere between them. The database is that memory — and the app server usually reaches it through a connection pool, often via an ORM.
Two families of storage
| SQL (Relational) | NoSQL | |
|---|---|---|
| Shape | Fixed schema: tables, rows, columns | Flexible: documents, key-value, graph |
| Relationships | Modeled with joins across tables | Often nested or denormalized |
| Good fit for | Structured data, strong consistency needs | Rapidly changing shapes, very large scale |
| Examples | PostgreSQL, MySQL | MongoDB, DynamoDB, Redis |
How relational data connects
- Primary keyUniquely identifies one row in a table, e.g.
user_id. - Foreign keyA column that points to another table's primary key — the mechanism behind relationships.
- JoinCombines rows from two tables based on a matching key.
Why some queries are instant
An index is a separate lookup structure the database maintains so it doesn't have to scan every row to find a match. It costs extra storage and slightly slower writes, in exchange for much faster reads.
ACID, in plain terms
A transaction groups several operations so they succeed or fail as one unit — critical when a single logical action touches multiple rows, like transferring money between two accounts.
Atomicity
All steps happen, or none do.
Consistency
The data moves between valid states only.
Isolation
Concurrent transactions don't corrupt each other.
Durability
Once committed, it survives a crash.
Auth & Security
HTTP is stateless by default, which raises an immediate question: how does a server remember who you are between requests, and how does it keep that trust from being abused?
Server-remembered state
The server creates a session, stores it server-side, and sends the browser a session ID cookie. The browser returns that ID on every request; the server looks up who it belongs to.
Self-contained proof
A JWT is a signed piece of data the client stores and sends with each request. The server verifies the signature instead of looking anything up — no server-side session storage needed.
Small data, sent automatically
A cookie is a key-value pair the browser stores and re-attaches to every matching request. Three flags matter most:
- HttpOnlyJavaScript can't read it — blunts XSS theft.
- SecureOnly sent over HTTPS.
- SameSiteRestricts cross-site sending — blunts CSRF.
Delegation and origins
OAuth lets an app access another service on your behalf — "Sign in with Google" — without ever handing over your password: redirect, consent, then an access token.
CORS is a browser rule that blocks a script on one origin from calling an API on another, unless that API explicitly opts in via a response header.
What to guard against
| Name | What happens | Common mitigation |
|---|---|---|
| XSS | Malicious script gets injected into a page other users load | Escape output, HttpOnly cookies |
| CSRF | A logged-in user's browser is tricked into firing an unwanted request | SameSite cookies, CSRF tokens |
| SQL Injection | Untrusted input is concatenated straight into a query | Parameterized queries / prepared statements |
Quiz
Nine questions across everything above. Pick an answer to see whether it's right.