In guide 1, Arjun built Meera's school library app and grew it to forty schools. That guide was about the data. This one is about the journey. Riya, a student, taps Reserve on her phone. A second later her phone says Reserved. What happened in between? (Meera, Arjun, Riya and every number here are made up for teaching.)
Think of sending a parcel. The address gets it to the right building. The room number gets it to the right desk. The form inside says what you want done. A network request works the same way:
An IP address routes traffic to a network interface. That's the building.
A port identifies one service on that machine. That's the desk.
An application protocol such as HTTP describes the conversation. That's the form.
The analogy has limits. An IP address can change, several devices can share one public address, and one service can run at many addresses.
Each section below starts with a real problem the library app hit:
Chapter
The problem
The idea it forces
1
"What actually happens when Riya taps Reserve?"
The four steps of a request
2
"It works on 4G but not on hostel Wi-Fi"
IP addresses, NAT, network layers
3
"We moved servers, and half the students still reach the old one"
DNS and TTL
4
"The connection said OK, but nothing was saved"
TCP, UDP, HTTP are different layers
5
"Riya tapped twice and got two reservations"
HTTP methods, idempotency, status codes
6
"The principal's dashboard needs different data than the phone"
REST, GraphQL, gRPC
7
"A mobile app arrived, and login is checked in four places"
Proxies, load balancers, gateways, BFFs
8
"Book covers load slowly in the village schools"
CDNs
9
"Students keep refreshing to see if the book is ready"
Polling, SSE, WebSockets
1. "What actually happens when Riya taps Reserve?"
The browser (or app) does four things, in order:
sequenceDiagram
participant R as DNS resolver
participant B as Browser
participant S as Library service
B->>R: 1. Find the address for library.example
R-->>B: Address
B->>S: 2. Open a connection and secure it
S-->>B: Ready
B->>S: 3. Send the HTTP request: GET /books/42
S-->>B: 4. Return a status code and the book data
Reading the diagram. Each numbered step is a different job, done by a different part of the system:
Find the address. The name library.example means nothing to the network, so the DNS resolver turns it into an IP address (chapter 3).
Open and secure a connection to that address (chapter 4).
Send the request. "Give me book 42" is written in HTTP (chapter 5).
Get an answer, with a status code that says how it went.
Caches and reused connections can skip steps 1 and 2 on later visits. That's why the second tap feels faster than the first.
Here is the smallest system that serves Riya's request:
Step 1: the smallest design that works.
You've reached the free preview of this post.
Subscribe to the Blogs plan (₹99/mo) — or use any Algomi Suite, Career, Investor, or Trader plan — to keep reading.
