System Design: a free course from zero to interview-ready

Think of it like this

Analogy

Sending a request is like posting a letter to a company you only know by name. First you look up their street address in a directory (DNS). Then you call ahead to make sure someone's there to receive it (the TCP handshake). You agree on a secret code so nobody can read it on the way (TLS). Finally you send the actual letter, written in a format both sides understand (HTTP), and wait for the reply.

The problem it solves

Every system design starts with a request crossing a network. If you don't know what happens on that trip, you can't explain why a page is slow, why a CDN helps, or why putting servers close to users matters.

Most of the time a slow first page load isn't slow code. It's the setup: several back-and-forth trips across the internet before the server even sees the request. Each trip costs one round-trip time, and across an ocean that's 100–200 ms every time.

A real example

Example

Opening a recipe site on café Wi-Fi

You tap a link to a recipe. Your phone first asks a DNS resolver for the site's IP address. The café's router has it cached from someone else's visit, so the answer comes back in a few milliseconds.

Next your phone opens a TCP connection and does a TLS handshake with the nearest CDN edge. That's a couple of round trips before any recipe data moves. Then it sends GET /recipes/lemon-cake. The edge doesn't have that page cached, so it asks the origin server, which reads the recipe from its database, builds the HTML and sends it back.

The HTML points to about 40 more files: photos, fonts, scripts. Those are cached at the edge, so they arrive fast over the connection that's already open.

How it works

A client, such as your browser, wants a page from a server. Here are the steps, in order.

1. DNS: find the address

Computers find each other by IP address, not by name. The browser asks a DNS resolver, usually run by your internet provider or a public service, “what's the address of shop.example.com?”. The resolver asks the name servers responsible for that domain and returns an answer like 203.0.113.10.

Answers carry a time to live, so the browser, the operating system and the resolver all cache them. Most requests skip this step entirely.

2. TCP: open a reliable connection

TCP makes sure bytes arrive complete and in order, resending anything lost. Opening a connection takes a three-step handshake (SYN, SYN-ACK, ACK), which costs one round trip.

3. TLS: agree on encryption

For HTTPS, the browser and server then run a TLS handshake. They check the server's certificate (proving it really is shop.example.com) and agree on encryption keys. Modern TLS 1.3 needs one round trip.

4. HTTP: ask for the page

Now the browser sends the actual HTTP request:

GET /products/42 HTTP/1.1
Host: shop.example.com
Accept: text/html
Cookie: session=abc123

The server replies with a status code, headers and a body:

HTTP/1.1 200 OK
Content-Type: text/html
Cache-Control: max-age=60
 
<html>…</html>

Status	Meaning	Example
2xx	Success	`200 OK`, `201 Created`
3xx	Look somewhere else	`301 Moved Permanently`, `304 Not Modified`
4xx	The client asked for something wrong	`400 Bad Request`, `401 Unauthorized`, `404 Not Found`, `429 Too Many Requests`
5xx	The server failed	`500 Internal Server Error`, `503 Service Unavailable`

A first HTTPS request: one round trip each for DNS (if not cached), TCP, TLS and the HTTP request itself.

5. The page asks for more

The HTML references images, styles and scripts, so the browser makes more requests, usually reusing the same connection. HTTP/2 and HTTP/3 send many requests over one connection at the same time. HTTP/3 runs over QUIC (on UDP), which combines the transport and TLS handshakes to save a round trip.

What this means for design

Distance is latency. Light in fiber takes about 100 ms to go from Europe to the US west coast and back. You can't optimize that away, only move closer: CDNs (lesson 15) and servers in more regions.
Reuse connections. Keep-alive and connection pooling skip the handshakes on later requests.
Cache DNS and content. Every cache hit is a round trip you don't pay.

Trade-offs

What you gain

HTTP is universal: every language, proxy, cache and tool understands it.
TLS gives privacy and proves the server's identity for very little cost on modern hardware.
DNS and HTTP caching remove most of the setup cost for repeat visits.

What it costs you

Each new connection costs several round trips, which hurts most for users far away.
DNS caching makes changes slow to spread: if you change an address, some clients keep the old one until the TTL expires.
HTTP is stateless, so anything like a login must be carried in every request (cookies or tokens).

When not to use it

For very chatty, real-time traffic like multiplayer games or live chat, many separate HTTP requests are wasteful. Use a long-lived connection such as a WebSocket (lesson 4).
For internal service-to-service calls at high volume, plain JSON over HTTP/1.1 can be inefficient; gRPC over HTTP/2 is often a better fit.

In the cloud

DNSEvery major cloud sells this as a managed service, so you configure it rather than build it.

AWS1

Amazon Route 53 (opens vendor docs)
Managed DNS that can also route by latency, location or health.

Azure2

Azure DNS (opens vendor docs)
Host your DNS zones on Azure's global name servers.
Azure Traffic Manager (opens vendor docs)
DNS-based traffic routing across regions, by priority, performance or location.

Google Cloud1

Cloud DNS (opens vendor docs)
Google's managed, low-latency authoritative DNS.

How you’d set it up

Your domain's DNS zone lives with the provider and points users at the public entry point.

Domain registrar
Route 53 hosted zone
Load balancer or CloudFront

Interview questions

Try answering out loud first, then open the model answer.

What happens when you type a URL into the browser and press Enter?

Model answer

The browser parses the URL and checks its caches. If it doesn't know the IP, it does a DNS lookup through a resolver, which may query the root, the top-level domain and the domain's authoritative name servers. With the IP, it opens a TCP connection (three-way handshake) and, for HTTPS, a TLS handshake that verifies the certificate and sets up keys. It sends an HTTP GET with headers such as Host and cookies. In a real system that request usually hits a CDN or load balancer first, then an app server that may read a cache or database. The response comes back with a status code, headers and HTML; the browser parses it, fetches the images, CSS and scripts it references, and renders the page.

Why might you lower a DNS record's TTL before a migration?

Model answer

Resolvers cache records for the TTL. If the TTL is a day and you move to new servers, some users keep going to the old address for up to a day. Lowering the TTL to a minute or so a day before the move means the switch spreads quickly. Afterwards you raise it again to cut DNS traffic and latency.

How do you make the first page load faster for users on another continent?

Model answer

Cut round trips and distance. Put a CDN in front so TLS ends at a nearby edge and static files are served from there. Use HTTP/2 or HTTP/3 so many files share one connection and handshakes are cheaper. Keep DNS TTLs reasonable. For dynamic content, run the app in more than one region and route users to the nearest healthy one.

Quiz

Pick an answer to see whether it’s right and why.

0 of 7 answered

Key terms

Client: The program that sends a request, such as a browser or a mobile app.
Server: A computer that waits for requests over a network and sends back responses.
DNS: The Domain Name System. It translates a name like example.com into the IP address of a machine.
IP address: The numeric address of a machine on a network, like 93.184.216.34.
TCP: The protocol that gives two machines a reliable, ordered stream of bytes, starting with a three-step handshake.
TLS / HTTPS: Encryption for data travelling over the network. HTTPS is HTTP sent over TLS.
HTTP: The request–response language browsers and servers speak, with methods like GET and POST and status codes like 200 and 404.
Round-trip time (RTT): How long a message takes to reach the other side and for the reply to come back.