Client, Server, Database & API: The 4 Words That Explain All Software

🟢 Fresher-friendly → 🔵 solid foundation

If you learn just four words properly — client, server, database, and API — you can understand how almost every app on Earth is built. Instagram, your banking app, food delivery, this website: all of them are these four pieces talking to each other. Most tutorials throw the words around assuming you already know them. This article does the opposite: it explains each one from zero, with an analogy you'll never forget, and then shows how they click together.

1. The client — the part you touch

The client is whatever you use: the app on your phone, the website in your browser. Its job is to show things nicely and collect what you do — taps, typing, scrolls — then send those as requests. The client is deliberately a bit "dumb": it doesn't hold the real data or the important rules. Why? Because anyone can open your phone's app and poke at it, so you can't trust it with secrets or final decisions.

Analogy: the client is the menu and the waiter's notepad at a restaurant. It shows you the options and takes your order — but it doesn't cook, and it doesn't decide the prices.

2. The server — the brain that does the work

The server is a computer, always on, sitting in a data centre. When a request arrives, the server runs your real logic: it checks if you're allowed to do this, calculates things, enforces the rules ("you can't withdraw more than your balance"), and talks to the database. Then it sends an answer back. All the trust and all the important decisions live here, where users can't tamper with them.

Analogy: the server is the kitchen. It receives orders, does the actual cooking, follows the recipes and rules, and plates the result. You never go into the kitchen — you just get the finished dish.

3. The database — the memory that never forgets

A database is where data is stored permanently, so it survives restarts, crashes, and years of time. Your account, your posts, your order history — all of it lives in a database. The server reads from and writes to it. When you "save" anything, it ends up here.

Analogy: the database is the restaurant's walk-in fridge and record book — the ingredients and the ledger of every order ever made. The kitchen (server) fetches from it and writes new entries to it, but the fridge itself doesn't cook.

Client  ──►  Server  ──►  Database
 (asks)     (decides)     (remembers)
        ◄──          ◄──

Which kind of database (a table-based SQL one, or a flexible NoSQL one) is a big design decision you'll meet in SQL vs NoSQL. For now: it's the thing that remembers.

4. The API — the agreed language between them

🔵 Here's the word that confuses everyone, made simple. An API (Application Programming Interface) is just a menu of things the server lets you ask for, and the exact format for asking. The client can't reach into the server and grab data however it likes — that would be chaos and a security nightmare. Instead, the server publishes a clear list of allowed requests, and the client uses those.

Analogy: the API is the menu itself. The menu tells you exactly what you can order and how ("Margherita pizza, choose a size"). You can't walk in and demand a random dish that isn't offered. The menu is the contract between customer and kitchen.

In practice, an API is a set of endpoints — specific URLs the server listens on. Each endpoint is one thing you can do:

GET   /users/42          → fetch user 42's profile
POST  /users             → create a new user
GET   /users/42/posts    → fetch user 42's posts
DELETE /posts/900        → delete post 900

Notice the pattern: a verb (what to do) plus a path (what to do it to). This tidy style is called REST, and it's the most common way APIs are built. There are other styles (gRPC, GraphQL) for special needs — all compared in API design.

What the server sends back: JSON

When the server answers an API request, it usually replies in JSON — a simple, readable text format that both machines and humans can understand. Ask for user 42, and you get back something like:

{
  "id": 42,
  "name": "Aarav",
  "city": "Pune",
  "posts": 128
}

The client receives this JSON and turns it into what you see on screen — a profile card, a list, whatever. That's the final handoff: data in, pixels out.

Putting it all together

Let's trace one real action — you tap a friend's profile in an app:

1. The client sends GET /users/42 to the server's API.
2. The server checks you're allowed, then asks the database for user 42.
3. The database returns the stored row; the server wraps it as JSON.
4. The client receives the JSON and paints the profile. Done.

Every feature in every app is a variation of this loop. Posting a photo? POST /photos. Liking it? POST /photos/900/likes. Once you see it, you can't unsee it.

Why this matters for system design

🔵 When you "design a system," you're really deciding how to make this four-part conversation fast and reliable at scale: many clients, many servers behind a load balancer, a database that won't buckle, and clean APIs between services. The clearer your API contracts, the easier everything else becomes — which is why big systems obsess over API design and why microservices are just "lots of small servers with APIs between them."

What to read next

• Latency, Throughput & Availability — how we measure fast and reliable
• Scaling from Zero to Millions — how this grows under load
• API Design: REST, gRPC & GraphQL — going deeper on APIs
• ← The complete System Design guide (hub)

← How the web works · Latency, throughput & availability →