Foundations — What Is a System, Really?

Before we touch a single buzzword, let’s nail the one idea everything else is built on: a system is just pieces that ask each other for things. Master that sentence and the rest of this track is detail. We’ll build the whole vocabulary from scratch — client, server, API, database, cache, queue, load balancer, CDN, DNS — and for each one, point at exactly where Assure PAT uses it (or honestly, where it doesn’t yet).

⏱ ~15 min · 🟢 Beginner · Prerequisites: the Start Here page

🎯 What you’ll be able to do after this page

• Explain what a “system” is, and the client/server split, to a non-technical friend
• Describe what’s actually inside an HTTP request and response — no hand-waving
• Define every building block (server, API, database, cache, queue, load balancer, CDN, DNS) in one sentence each, with an analogy
• Say which of those Assure PAT uses, and which it doesn’t (yet)
• Tell frontend from backend and know what lives where
• Read a real boxes-and-arrows diagram out loud and narrate exactly what happens

1. What a “system” actually is

A system is two or more pieces of software that talk to each other to get a job done. That’s the whole idea. The moment one piece of code asks another piece of code for something, you have a system.

The most fundamental split in all of software is between the piece that asks and the piece that answers:

The one distinction to burn into your brain

• The client is whoever asks for something. (“Give me my profiles.”)
• The server is whoever answers. (“Here are your 12 profiles.”)

That’s it. Client asks, server answers. Everything from a web browser to a mobile app to one program calling another is just this pattern, repeated.

The analogy: ordering at a counter

You walk up to a coffee counter. You are the client — you place an order. The barista is the server — they take your order, do work behind the counter, and hand something back. You don’t go behind the counter and make the coffee yourself; you ask, and you receive. The counter is the boundary between you and the machinery.

In Assure PAT, there are three different clients all talking to one server:

flowchart LR
    Web["React Dashboard<br/>(browser)"] -->|asks| API["Express API<br/>(the server)"]
    Mobile["Android App<br/>(NFC tester)"] -->|asks| API
    Admin["System Admin<br/>panel"] -->|asks| API
    API -->|answers| Web
    API -->|answers| Mobile
    API -->|answers| Admin

Read it aloud: “Three clients — the web dashboard, the mobile app, and the admin panel — all ask the same Express API, and it answers all of them.” One server, many clients. This is normal and good: write the logic once, serve everyone.

2. The request/response model over HTTP

When a client asks and a server answers over the web, they speak a language called HTTP. Don’t be scared of it — HTTP is just a very strict format for “here’s what I want” and “here’s your answer.”

Every exchange is exactly two messages: a request (client → server) and a response (server → client). Let’s open them up.

What’s inside a request

A request has four parts:

The methods are just verbs — memorise these four

• GET = “show me” (read, changes nothing)
• POST = “create this” (make something new)
• PUT = “update this” (change something that exists)
• DELETE = “remove this”

So GET /api/v2/profiles literally reads as: “Show me the profiles.” The Assure backend’s whole API is built from these verbs on URLs that start with /api/v2/.

What’s inside a response

The answer has three parts:

Status codes, by their first digit

• 2xx = it worked (200 OK, 201 created)
• 3xx = go look somewhere else (redirect)
• 4xx = you messed up (401 not authenticated, 403 not allowed, 404 not found)
• 5xx = the server messed up (500 internal error)

When something breaks, the first digit tells you whose fault it is. That alone saves hours of debugging.

One full round-trip, drawn out

Here’s a real Assure PAT exchange — loading the profiles list — as a sequence diagram. Time flows downward. A solid arrow ->> is a call; a dashed arrow -->> is the answer coming back.

sequenceDiagram
    participant B as Browser (client)
    participant A as Express API (server)
    participant D as MySQL (database)
    B->>A: GET /api/v2/profiles<br/>Authorization: Bearer token
    A->>A: check token, find org_id
    A->>D: SELECT * FROM profiles WHERE org_id = ?
    D-->>A: rows
    A-->>B: 200 OK { profiles: [...] }

Narrate it: “The browser sends a GET request with its token. The API checks the token, figures out which org you belong to, asks MySQL for that org’s profiles, gets rows back, and replies 200 with the data.” If you can say that, you understand the request/response model. Everything in this track is variations on this one picture.

Now watch it happen hop by hop. This visualizer traces one click through the full stack and back — step through it and say each hop out loud before clicking next:

3. The building blocks — your core vocabulary

Here is every word people throw around in system design. For each: what it is (one line), why it exists, a homely analogy, and how Assure PAT uses it — honestly, including the ones it doesn’t.

3.1 Client

• What it is: the software that asks — usually what a human looks at.
• Why it exists: humans need a screen to interact with; the client is that screen.
• Analogy: the customer at the counter.
• In Assure PAT: three of them — the React 18 + Vite web dashboard, the Android/Kotlin mobile app (which emulates payment cards over NFC and taps real terminals), and the internal System Admin panel.

3.2 Server

• What it is: the software that answers — does the real work, holds the rules.
• Why it exists: you don’t want business logic and secrets living on every user’s device; you centralise them.
• Analogy: the barista behind the counter.
• In Assure PAT: a Node.js + Express 5 backend. It runs serverlessly on AWS Lambda (more on that in section 4).

3.3 API

• What it is: the menu of things the server will do for you, and how to ask.
• Why it exists: a client needs to know exactly what it can request and in what format. The API is that contract.
• Analogy: the printed menu at the counter — it lists what you can order and what you’ll get.
• In Assure PAT: every endpoint under /api/v2/... — e.g. /api/v2/profiles, /api/v2/cards, /api/v2/auth/login. That path is the menu.

3.4 Database

• What it is: the place that stores data permanently and lets you query it.
• Why it exists: memory vanishes when a program stops; you need data to survive and be searchable.
• Analogy: the pantry — organised shelves you can pull from and restock.
• In Assure PAT: MySQL 8, schema assurepat, accessed through a query-builder library called Knex. Every table has an org_id so one customer’s data never leaks into another’s.

3.5 Cache

• What it is: a small, fast store for answers you’ve fetched recently, so you don’t redo expensive work.
• Why it exists: databases are relatively slow; if the same answer is asked for constantly, keep a hot copy nearby.
• Analogy: the barista keeping a jug of milk on the counter instead of walking to the fridge for every cup.
• In Assure PAT: not used in the core path (yet). This is a very common building block, but Assure currently reads straight from MySQL. Worth knowing because you’ll meet it everywhere else.

3.6 Message Queue

• What it is: a waiting line for tasks, so work can be handed off and done later instead of right now.
• Why it exists: some jobs are slow (sending email, processing files). A queue lets the server say “I’ll get to it” and answer the user immediately.
• Analogy: the order tickets clipped on a rail — orders queue up and get worked through in turn.
• In Assure PAT: not used in the core path (yet). Another standard block Assure mostly doesn’t reach for today.

3.7 Load Balancer

• What it is: a traffic director that spreads incoming requests across many copies of a server.
• Why it exists: one server can only handle so much; run several and split the load so no single one drowns.
• Analogy: a host at a busy restaurant sending guests to whichever waiter is free.
• In Assure PAT: mostly handled for you by AWS. Because the API runs on Lambda + API Gateway, AWS spins up and spreads requests across instances automatically — you don’t manage a load balancer box yourself.

3.8 CDN (Content Delivery Network)

• What it is: a network of servers around the world that keep copies of static files close to users.
• Why it exists: the speed of light is finite; serving a file from a city near the user beats crossing the planet.
• Analogy: a chain coffee shop with branches everywhere, so you never travel far for the same drink.
• In Assure PAT: the company domain (ayrisglobal.com) sits behind Cloudflare, which can serve static frontend assets from edge locations. (You explored this on the web-infrastructure case-study page.)

3.9 DNS (Domain Name System)

• What it is: the phonebook of the internet — it turns names like assure.ayrisglobal.com into IP addresses.
• Why it exists: humans remember names; computers route by numbers. DNS bridges the two.
• Analogy: looking up a contact’s name in your phone to get their number.
• In Assure PAT: DNS for the domain is run by Cloudflare (the authoritative nameservers). Type the app’s address and DNS is what finds the right machine.

The honest scorecard

Assure PAT uses today: Client (×3), Server, API, Database (MySQL), file store (S3), and — via AWS — load balancing, plus a CDN (Cloudflare) and DNS at the edge. Assure PAT does not use yet: a dedicated cache server or a message queue in its core path. That’s not a flaw — you add those when scale demands them. Knowing the whole vocabulary lets you spot the day they’ll help.

4. Stateless vs stateful

This sounds fancy; it’s simple.

• Stateful = the server remembers you between requests. It keeps a little memory of “this is Darshan, mid-way through step 3.”
• Stateless = the server remembers nothing between requests. Every request must carry everything needed to handle it — usually a token that says who you are.

The analogy that makes it click

• Stateful = a regular at a café whose barista remembers their usual. Lovely — but only works if you always get the same barista.
• Stateless = a coffee shop where you show a ticket every time. Any barista can serve you, because the ticket carries all the info. Slightly more to hand over each time, but anyone can help you — which is exactly what you need when there are many baristas.

Why this matters for Assure PAT: the API runs on AWS Lambda, which is stateless by design. AWS may spin up a fresh copy of the server for any request and throw it away after — so the server can’t rely on remembering you. That’s why every request carries a JWT token (bhtoken for web users) in its Authorization header: the token is the ticket. The server reads it fresh each time to know who you are and which org you’re in. Stateless servers are easy to scale precisely because any copy can handle any request.

5. Frontend vs backend — what lives where

Two words you’ll hear constantly. The line between them is the client/server boundary from section 1, viewed from a developer’s chair.

flowchart LR
    subgraph FE["FRONTEND — on the user's device"]
        UI["React / Android UI"]
    end
    subgraph BE["BACKEND — on AWS"]
        API["Express API"]
        DB[("MySQL")]
        S3[("S3 files")]
    end
    UI -->|"HTTPS request"| API
    API --> DB
    API --> S3

The golden security rule this boundary enforces

Never trust the frontend. Anyone can open browser dev-tools and fake a request. So all the real checks — are you logged in? are you allowed? does this belong to your org? — happen on the backend. The frontend is for showing; the backend is for deciding. Assure does exactly this: tokens are verified and org_id is enforced on the server, every request.

6. “You can now read this” — narrate a tiny web app

Here is a small but complete picture of a real web system, using every block we’ve named. This is the city map view — all the common pieces arranged together.

flowchart TD
    User(["User"]) --> DNS["DNS<br/>(find the address)"]
    DNS --> CDN["CDN<br/>(static files, nearby)"]
    CDN --> LB["Load Balancer<br/>(spread the traffic)"]
    LB --> S1["Server copy 1"]
    LB --> S2["Server copy 2"]
    S1 --> Cache["Cache<br/>(fast recent answers)"]
    S2 --> Cache
    S1 --> DB[("Database<br/>(the source of truth)")]
    S2 --> DB
    S1 --> Q["Queue<br/>(slow jobs, later)"]

Now you narrate it (this is the whole skill — try it before reading on):

How this maps to Assure PAT specifically

Assure’s version of that map is leaner — and that’s correct for its stage: DNS = Cloudflare · CDN = Cloudflare (frontend assets) · Load balancer + server copies = AWS API Gateway + Lambda (automatic) · Database = MySQL on RDS · plus S3 for files and KMS for crypto keys. Cache and Queue are greyed out — not in the core path yet. Same city, fewer buildings.

✅ Check yourself

Still Unclear?

Copy any of these into Claude to go deeper on the exact spot you’re stuck:

• “Explain the client/server split using an example that is NOT a coffee shop — pick a system I use every day and show me which part asks and which part answers.”
• “I have the HTTP request and response parts memorised but they feel abstract. Give me three real curl commands against a public API and tell me exactly what method, URL, headers, body, status code, and response body each one produces.”
• “Quiz me on the nine building blocks (client, server, API, database, cache, queue, load balancer, CDN, DNS) one at a time — show me a scenario and make me name which block solves it, then tell me if I’m right.”

Why AI Can’t Do This For You

AI can recite that “a load balancer spreads traffic” in a heartbeat — but it can’t look at your system and tell you whether you actually need one yet, the way the honest Assure PAT scorecard does. The skill this page builds is judgment about which blocks a real system reaches for and which it deliberately skips — knowing that “no cache yet” is a correct decision at this stage, not a gap. Reading a boxes-and-arrows diagram out loud and narrating what truly happens is a muscle you only get by tracing real requests yourself. When an interviewer points at a diagram and asks “what happens when a user clicks here?”, you have to narrate it live — and when production breaks at 2am, no prompt will trace the request for you faster than your own trained eye.

One-line summary

A system is just pieces that ask each other for things over HTTP — a client asks, a server answers — and every buzzword (cache, queue, load balancer, CDN, DNS) is either one of those pieces or a way to make them faster or safer. Assure PAT uses a clean, lean subset of them, and now you can name every one.

Next up: the Layered Architecture page, where we go inside that one “server” box and discover it’s secretly several neat layers stacked on top of each other. 👉

Module done? Add it to today’s tracker