How a web request travels
Follow one click through the network, your application and its data, then back to the user.
Visual model
One request, three core roles
Start with the path, not the boxes
A click becomes an HTTP request. DNS finds your service, the request crosses the network and an application server decides what happens next.
The server may read a cache, query a database, call another service or enqueue work. Then it returns a response.
Start system design with this path. Know where the request enters, where the work happens, where the source of truth lives and what returns to the user.
The smallest useful system
A first version often needs only three roles: a client, an application server and a database.
That shape can serve real users. Add complexity only when a measured problem appears.
- Client: the browser or app that starts the request and renders the response.
- Application server: validates input, applies business logic and coordinates other components.
- Database: the durable source of truth that survives application restarts.
- Network: every hop costs time and can fail, even when your code is correct.
What changes when traffic grows
More users put pressure on the same path. The app may run out of CPU or connections. Repeated reads may overload the database. Slow tasks may keep requests open.
Each lesson introduces one tool for one of these pressures.
The goal is not to draw the most boxes. It is to find the first bottleneck, make one justified change, and check what new trade-off that change creates.
See it
Add one tool for one pressure
Key takeaways
- Trace the request path before choosing infrastructure.
- Start with client, application and database. Add complexity for a measured reason.
- Every network hop costs latency and introduces another place that can fail.