DSA TrainerSystem Design · Unit 2
The request path
Someone opens your app and taps a button. A fraction of a second later, they see a result. In between, that request traveled through several distinct pieces, each with one job. If you can picture that journey, most of system design stops feeling like a pile of unrelated buzzwords and starts feeling like slots on a map.
The path, at its simplest, is: the user's device (the client) finds your servers, a traffic director sends the request to one of them, that server runs your code, and it reads or writes a database that holds the real data. Then the response travels back.
This unit walks that path once, slowly. Every other unit in this track, load balancing, caching, databases, replication, is really "let's zoom in on one stop along this route." Get the route in your head first.
You’re not signed in. Your progress here won’t be saved.
The journey, end to end
Here is the whole trip for a typical request. The client (a browser or phone app) needs to reach your servers, but it only knows your domain name, like example.com. So first it looks up the address for that name. With an address in hand, the request goes to a load balancer, a single front door that decides which of your servers should handle it. That server runs your application code, which usually needs data, so it talks to a database, the durable source of truth. The server builds a response and it travels back to the client.
That is the spine: client, name lookup, load balancer, server, database. Everything else is an optimization you insert somewhere along this line.
In the simple request path, what is the database's role?