System Design
Simple client-server architecture is fundamental to system design because any system you build is essentially a scaled-up version of this with more pieces. You need to understand the most basic form first: a client talking to a server. You won't end there—there will be more servers, more components, more things talking to each other on the backend. But always start with the basic client-server architecture and build up from there.
No diagram content
A client is usually a web application or mobile phone. It's the end user—a human—interacting with your system through a website, an app, or some other interface. The client has a user interface to view and use your app, so we call this the view tier.
The client makes requests to servers and receives responses—data or HTML—back.
The server receives requests from clients and responds with data or HTML. On the server we have business logic: APIs, endpoints, routing, and application logic. We call this the web tier.
The server may also need to persist data or write to a database. That's another layer—the data tier.
So we have:
The server talks to the database. It's a good idea to keep these independent so you can:
With most systems, keeping things modular like this lets you scale and maintain each part on its own.
Clients and servers communicate using the HTTP protocol. The client finds the IP address of the server using DNS—when the user enters a URL, a DNS lookup converts it to an IP address, and the client uses that to send the request.
That's the essence of client-server architecture: client → server → database, each layer independent and communicating over HTTP.