What are clients and servers?
A client is the thing asking (your phone, your browser, another program). A server is the thing answering — a computer that sits waiting for questions and returns answers. That is the entire idea: one side asks, the other side answers.
One conversation is a request (the question: "give me the menu for Tony's Pizza") followed by a response (the answer: the menu data, or an error). Everything on the internet — every tap, every page load, every message sent — is this same ask-answer loop repeated millions of times.
- request
- — the message a client sends: what it wants, plus any data needed
- response
- — the server's reply: the result, or an error explaining what went wrong
Words to know
Trace one tap, end to end
You tap "Place order" in SliceNow. Watch the 300 milliseconds that follow.
- Your phone (the client) builds a request: "create an order: 1 large pepperoni, deliver to 12 Oak St" and sends it to
slicenow.com. - The server receives it, checks it makes sense (is the store open? is the address real?), and writes a new order row into the database.
- The server builds a response: "order #4817 confirmed, ready in 25 min" and sends it back.
- Your phone reads the response and shows the confirmation screen.
Every system you will ever design is this loop with more helpers bolted on. The helpers (load balancers, caches) exist to keep this loop fast when millions of taps arrive at once.
Request travels
~50 ms
Server thinks + saves
~200 ms
Response returns
~50 ms
Quick check
The SliceNow server needs to charge a card, so it sends a request to Stripe (a payment company) and waits for the answer. In THAT conversation, who is the client?
What is an API?
An API is the server's published menu of questions it is willing to answer, and the exact format for asking. Just like a restaurant menu: you can order what is on it, in the form it is written, and you know roughly what you will get back.
Each item on the menu is an endpoint — one askable thing. POST /orders means "create an order" (you send the order details, you get back an order id). GET /orders/4817 means "show me order 4817". The verb says what KIND of ask it is: GET reads without changing anything, POST creates something new, and the path says which thing you are talking about.
Why this matters for design: when you list a system's endpoints, you are really listing everything the system can do. That is why interviews ask for the API right after the requirements — each "the user can..." requirement should map to an endpoint.
- endpoint
- — one askable operation: a verb (GET/POST) plus a path (/orders)
- GET vs POST
- — GET reads and changes nothing; POST creates or changes something
Words to know
SliceNow's API, as a menu
Notice how each endpoint traces straight back to a requirement.
| Requirement | Endpoint | Sends | Gets back |
|---|---|---|---|
| Browse the menu | GET /restaurants/{id}/menu | nothing | list of items + prices |
| Place an order | POST /orders | items, address, payment token | order id + ETA |
| Track my order | GET /orders/{id} | nothing | status: baking → out for delivery |
| Cancel my order | POST /orders/{id}/cancel | nothing | confirmation (or "too late") |
Quick check
New requirement: "customers can save a favorite restaurant." Which endpoint fits best?
Common trap — The double-tap problem
Networks fail mid-request, and users double-tap buttons. If "Place order" is sent twice, should two pizzas arrive? Well-designed APIs handle repeats safely (e.g. the client sends a unique order token, and the server ignores a second request with the same token). Interviewers love asking this — "what happens if this request arrives twice?" is always worth a sentence.
Match them up
Match each term to its plain meaning.
0/5 matched — tap a term on the left.
Build it yourself
Build the smallest real system: the customer's app talks to a server, and the server keeps orders somewhere safe. Drag the pieces on and connect them in the direction requests flow. One of these components is not needed yet — leave it off.
Quick check
Why do we draw Client → Server and not Server → Client?