What happens when you tap a button

Part of the free System Design course on LogicWiz, in the chapter: System design from zero. The interactive whiteboard exercises and simulations run in the app.

One tap, many machines

"I thought the app had my order inside it. Then my train went into a tunnel, and the tracking screen froze."

Meera, on her first morning at SwiftKart

Meet Meera, Kabir and this course

Meera has joined SwiftKart as an SDE-2, a software engineer a few years into the job. SwiftKart is a quick-commerce app: you order groceries, and a rider brings them in about 10 minutes. About 2 million people use it every day.

Her tech lead, Kabir, guides her through her first weeks. You will learn alongside her. The course has three parts:

  • Foundations: what a request is, how a small system grows, the words designers use, how a design interview runs, and quick estimates.
  • Theory: one chapter for each big piece of a system, such as the front door every request walks through (the entry layer), databases, caches, queues and reliability.
  • Interview questions: the designs interviewers ask for most, worked through step by step.

You need no background. Every new word is explained the first time it appears.

On day one, Kabir asks a simple question. "A customer taps Track order. What happens?" Meera says, "The app shows the status." Kabir asks, "Where does the app get the status from?" Meera thinks of the tunnel. With no network, the screen froze. So the status was never inside her phone. It lives somewhere else, and the phone has to ask for it every time.

Client and server: the one who asks and the one who answers

The program the customer touches is the client. The SwiftKart app on a phone is a client. A website open in a browser is also a client. The client shows screens and collects taps. It keeps only a little data, such as the last screen it showed.

The program that answers is the server. A server is a program that waits for requests and answers them. It runs on a computer in a data centre, a building full of computers with steady power, cooling and fast network links. People also say "server" for the computer itself; the context tells you which one they mean.

Think of a restaurant. You, the client, tell the waiter what you want. The kitchen, the server, cooks it and sends it out. You never walk into the kitchen. The analogy stops in two places. A server answers thousands of customers at the same moment, not one table at a time. And it answers in milliseconds (thousandths of a second), not in twenty minutes.

Many beginners picture one huge computer that does everything for SwiftKart. It is closer to a team. One program handles orders, another handles payments, another stores the data. Each runs as several identical copies on different machines. If one machine fails, the copies on the others keep answering. The next lesson shows how SwiftKart grew from one machine into this team.

Finding the server: IP addresses and DNS

To send a request, the phone needs the server's address. On the internet, every machine has an IP address, a number such as 203.0.113.10. Networks deliver messages by this number, the way the post office delivers letters by PIN code.

People cannot remember numbers like that, so we use names such as api.swiftkart.example. DNS (the Domain Name System) turns a name into an IP address. It is the internet's phone book: you look up a name and get a number.

A DNS lookup takes roughly 20 to 50 milliseconds. The phone then remembers the answer for a while, often a minute or more, so the next tap skips the lookup. DNS can also give different callers different addresses, such as the nearest data centre. The entry-layer chapter returns to that.

The request and the response, in HTTP

The phone and the server must agree on how to talk. That agreement is a protocol, and apps use HTTP (Hypertext Transfer Protocol). The phone sends a request. The server sends back a response. Here is the Track order tap, written out in full:

GET /orders/123 HTTP/1.1
Host: api.swiftkart.example
Authorization: Bearer eyJhbGc...

HTTP/1.1 200 OK
Content-Type: application/json

{"orderId": 123, "status": "PICKED_UP", "etaMinutes": 6}

Read it piece by piece.

  • Method: GET means "give me something". POST means "create something", such as a new order.
  • Path: /orders/123 names the thing you want: order number 123.
  • Headers: short labelled notes that travel with the message. Authorization carries a token, a string that proves who the customer is.
  • Body: the content itself. Here the response body is JSON, a plain-text format of names and values that every programming language can read.

Every response starts with a status code, a three-digit number that says how it went. You will see these often:

  • 200 OK: here is what you asked for.
  • 201 Created: the new thing, such as an order, now exists.
  • 400 Bad Request: your request is malformed, such as an order with no address.
  • 401 Unauthorized: we do not know who you are; log in again.
  • 404 Not Found: there is no order with that number.
  • 429 Too Many Requests: slow down, you are sending too many.
  • 500 Internal Server Error: something broke on our side.
  • 503 Service Unavailable: we are overloaded or down for now; try again later.

Codes that start with 4 mean the client should change something. Codes that start with 5 mean the server has a problem.

The full list of requests a server accepts is its API (application programming interface). It is the server's menu. GET /orders/{id} and POST /orders are two items on SwiftKart's menu. A client can only ask for what is on the menu. The APIs chapter shows how to design a good one.

Where the data survives: the database

The order service could keep every order in its own memory (RAM). Memory is fast, but it is wiped whenever the program restarts. Servers restart often: for a new release, after a crash, or when a machine is replaced. An order kept only in memory would vanish.

So the data lives in a database, a program built to store data on disk and find it again quickly. When the order service restarts, the database still has order 123. Think of the service's memory as a whiteboard that is wiped every night, and the database as the shop's register book. The analogy has a limit: a real database can keep copies on several machines, so one broken disk loses nothing.

The client never talks to the database directly. The server sits in between. It checks who is asking, reads only what that customer may see, and sends it back. A phone with a direct line into the database would let anyone read anyone's orders.

One tap, with a stopwatch

Now follow the tap from start to finish. The times are rough but realistic for a phone on 4G in India, talking to a data centre in Mumbai.

sequenceDiagram
  participant P as Phone
  participant D as DNS
  participant S as Order service
  participant B as Database
  P->>D: address of api.swiftkart.example?
  D-->>P: 203.0.113.10
  P->>S: GET /orders/123
  S->>B: read order 123
  B-->>S: status PICKED_UP
  S-->>P: 200 OK with JSON
  1. DNS lookup: about 30 ms. Skipped when the phone remembers the answer.
  2. Opening a secure connection: a short exchange so nobody else can read the traffic. About 80 ms, and later taps reuse it.
  3. The request travels to Mumbai: about 20 ms.
  4. The service checks the token and asks the database: the query takes about 2 ms, and the service adds about 3 ms.
  5. The response travels back: about 20 ms.
  6. The app draws the screen: about 15 ms.

Add them up. The first tap takes about 170 ms. The next tap skips steps 1 and 2 and takes about 60 ms. The time from a tap to its answer is called latency, and it is the sum of every step on the path.

Now look at where the time went. The service and the database used about 5 ms. The network used almost all the rest. Making the database twice as fast would save 1 ms. Avoiding one extra trip to Mumbai would save 40 ms.

💡 Tip: When something is slow, list the steps and put a number on each one. The slow step is usually a trip across the network, not the code.

Now draw the path yourself. The starter below has a mistake that real teams make: the app talks straight to the database.

📌 Summary: A client sends an HTTP request and a server answers with a status code and data. DNS finds the server, the database keeps data through restarts, and latency is the sum of every step.

What Meera learns next

One server answering one tap is easy. Next, Meera learns how SwiftKart grew from a single machine into a system that serves millions, one problem at a time.

Check your understanding

  1. Meera's train enters a tunnel and the tracking screen stops updating, although the app is still open. What does this tell her?
  2. A customer opens an old link to order 999999, which never existed. Which status code should the order service send back?
  3. A Track order tap takes about 60 ms: about 40 ms on the network, 5 ms in the service and database, 15 ms drawing. A teammate wants a database twice as fast. What is the honest answer?
  4. To save one hop, a teammate suggests the app read orders straight from the database. What is the main problem?