InterviewKata
System design · Level 0: Basics · Module B1 of 6

What a system is made of: clients, servers, APIs and databases

Before you can design a system, you need its vocabulary. Every app you use, from a to-do list to a bank, is built from the same few parts: something that asks (a client), something that answers (a server), an agreed way of asking (an API), and somewhere the data is kept (a database). This module explains each part from zero and shows one request moving through all of them.

1. The idea

A restaurant. You (the client) never walk into the kitchen. You read the menu (the API: what you're allowed to ask for), tell the waiter your order (a request), the kitchen (the server) cooks it using ingredients from the pantry (the database), and the waiter brings back your plate (the response). Many diners, one kitchen; the kitchen doesn't need to remember you once your plate has left.

Here is the same picture in technical words. Each term below is used in every later module, so it's worth being able to say each one in a sentence.

TermWhat it meansExample
ClientThe program that starts a conversation by sending a request.A web browser, a phone app, another server calling yours
ServerA program (and, loosely, the machine it runs on) that waits for requests and answers them.The program behind api.example.com
Request and responseOne question and its answer. On the web they're usually HTTP messages: a method and a path in, a status code and a body out.GET /notes/7 → 200 OK with the note
APIApplication programming interface: the list of requests a server accepts and what each returns. A contract between client and server."POST /notes creates a note and returns its ID"
Frontend and backendThe frontend is what runs on the user's device (pages, buttons). The backend is everything on your servers.A React page (frontend) calling a Python API (backend)
Web serverA server that speaks HTTP to the outside world: serves files, terminates HTTPS, forwards other requests.Nginx, Caddy, a CDN edge
Application serverWhere your own code runs: the business logic ("is this user allowed?", "what's the total?").A Node.js, Java, Go or Python service
DatabaseA program that stores data safely on disk and finds it again quickly.PostgreSQL, MySQL, MongoDB
StatelessA server that keeps nothing about a user between requests; everything it needs arrives with the request or lives in a shared store.Any of 10 identical app servers can answer you

Put together, most applications have three tiers: a presentation tier (the client), a logic tier (application servers) and a data tier (databases). Almost every design in this course is these three tiers, plus parts added to make them faster, bigger or safer.

2. How it works

A web page usually arrives in two steps. First the browser fetches the page's files (HTML, JavaScript, images), which are the same for everyone and often come from a web server or a CDN. Then the JavaScript in that page asks the API for this user's data, which the application server builds from the database. Phone apps skip the first step: the app is already installed, so they only call the API.

One request, step by step

Here is what happens when you open note 7 in a notes app. Each step is one hop; press Play or use the arrow keys.

Stateful vs stateless servers

When one server isn't enough, you run several copies behind a load balancer (Module 08). That only works if any copy can answer any request. If a server keeps your login in its own memory, the next request may land on a different server that has never heard of you.

3. Try it yourself

Talk to an API

A notes app has a small REST API. Pick an action and the conditions, and see the exact request your client sends and the response the server returns.

Request

Response

      

    

    
Where should the login live?

    
Four requests from one user arrive through a load balancer that takes turns between the app servers. Choose where the server remembers that the user is signed in, how many servers there are, and whether one restarts halfway.

    

      

      

      

      

    


    
    
4. Trade-offs

    

      
Stateless vs stateful servers
Stateless servers can be added, removed or restarted freely, because nothing is lost. The price is a round trip to a shared store (or a larger request) to fetch the state each time. Keep state in servers only when you must, as with live chat connections (Module 19).

      
One server vs separate tiers
Running the code and the database on one machine is simplest and fine for a new product. Separating them lets each be sized, scaled and secured on its own, at the cost of a network hop and more machines to run.

      
Pages built on the server vs in the browser
Server-rendered pages show content faster on first load and are easy for search engines. Browser-rendered apps (single-page apps) feel smoother once loaded and reuse the same API as the phone apps. Many sites mix both.

      
Managed vs self-run databases
A cloud provider's managed database handles backups, patches and failover for a higher price per machine. Running your own gives control and lower raw cost, but your team does the 3 a.m. recovery.

    


    
    
5. In real systems

    
A typical web product today looks like this. Every row is a later module.

    

      
LayerJobCommon choicesLearn more

      
        
ClientShows the interface, calls the APIBrowser apps (React, Vue, plain HTML), iOS and Android apps01

        
EdgeFinds the server, serves static files from nearby, blocks attacksDNS, CDNs10

        
Front doorHTTPS, routing, spreading loadLoad balancers, reverse proxies (Nginx, Envoy), API gateways08

        
Application serversYour business logic, statelessNode.js, Python, Java, Go, often in containers07

        
DataKeeping data safe and findableRelational databases (PostgreSQL, MySQL), caches (Redis), file storage (object stores)11, 09

        
Background workSlow jobs users shouldn't wait forQueues and workers18

      
    

    
Say it in the interview

    
Two-sentence answers
    
      
  • "What's an API?" The contract a server offers: which requests it accepts and what each returns. Clients depend only on that contract, so the server can change inside without breaking them.
    • 
      
  • "Why stateless servers?" So any copy can serve any request: we can add servers for load, remove them, or lose one without users noticing. State goes to a database, a cache or a signed token.
    • 
      
  • "Web server vs application server?" The web server handles HTTP itself (files, HTTPS, forwarding); the application server runs our code. Small apps combine them; large ones separate them.
    • 
    

    
Red flags interviewers notice
    
      
  • The browser talking directly to the database: nothing would check permissions.
    • 
      
  • Sessions kept in one server's memory behind a load balancer.
    • 
      
  • Using "server" for the machine, the program and the whole backend interchangeably without noticing.
    • 
    


    
    
6. Remember it

    
Memory hook: "Ask, answer, keep"The client asks, the server answers, the database keeps. Anything else in a design exists to make one of those three faster, bigger or safer.

    

      How this hook works: what "Ask, answer, keep" means
      
What the slogan means, phrase by phrase

      

        
"Ask"
The client sends a request through an API: it never reaches into the server's insides.

        
"answer"
The server runs the logic and replies, then forgets the request (stateless).

        
"keep"
Only the database is responsible for remembering, safely, on disk.

      

      
Why this picture fits: it separates the three responsibilities, and most beginner mistakes mix two of them (the client keeping secrets, the server keeping state).

      
The story → the concept

      

        
RestaurantSystem

        
          
DinerClient

          
MenuAPI

          
WaiterRequest and response (and the web server that carries them)

          
KitchenApplication server

          
PantryDatabase

        
      

      
Watch it on an example

      
    
        
  1. Ask: the phone app sends POST /orders with the items.
    2. 
        
  2. Answer: the app server checks stock and prices, then saves the order.
    3. 
        
  3. Keep: the database stores the order; the app server keeps nothing, so any copy could have handled it.
    4. 
      

      
The trap it saves you from

      
Putting memory in the wrong place: a total computed only in the browser (which a user can change), or a cart held in one server's memory.

    


    
    
7. Common mistakes

    
Trusting the clientAnything the client sends can be changed by the user: prices, user IDs, "isAdmin". The server must check everything and take identity from a verified login, never from the request body.

    
State in one server's memoryWorks on your laptop, breaks as soon as there are two servers or one restarts. Use a shared session store or a signed token.

    
Thinking the API is the backendThe API is only the contract. Behind it can be one server or a hundred services, and that can change without clients noticing.

    
Ignoring the static half of a pageThe HTML, JavaScript and images are most of the bytes. They belong on a CDN, not on your application servers.


    
    
8. Design exercise (20 minutes)

    
    
      
  1. Draw three apps (10 min). For a to-do list, a photo-sharing app and a chat app, draw client, API, application server and database. Write the three most important API requests for each.
    2. 
      
  2. Find the state (5 min). In each app, list what must be remembered between requests (sessions, uploaded photos, unread messages) and where you'd keep it.
    3. 
      
  3. Break it (5 min). For each app, say what users see if the database is down, and if one of two application servers crashes.
    4. 
    


    
    
9. Self-check quiz

    

      

        
A browser needs a user's orders. What should it talk to?

        

        
The server is the only place that can enforce who may see what. The database is never exposed to clients.

      

      

        
What does "stateless server" buy you?

        

        
That's what lets you add, remove and restart servers freely.

      

      

        
A request arrives with no login. Which response fits?

        

        
4xx codes mean the client must change something; 5xx means the server failed.

      

      

        
What is an API?

        

        
It's a contract; the code behind it can change freely.

      

      

        
Where should a site's images and JavaScript files be served from?

        

        
They're the same for everyone, so serve them from caches near users.

      

    


    
    
10. Go deeper

    

      
ResourceTimeWhy

      
        
Client-server overview (MDN)20 minHow a website's client and server divide the work, with examples.

        
An overview of HTTP and status codes (MDN)25 minThe messages clients and servers exchange.

        
The Twelve-Factor App: processes5 minThe classic short case for stateless processes.

        
Presentation, domain, data layering (Martin Fowler)10 minWhy applications are split into these three layers.