System Design & Architecture — Start Here

Most “system design” courses throw a load balancer at you on page one and hope you nod along. This track does the opposite. We build the vocabulary from the ground up, and every single idea is anchored to one real system you already have access to: Assure PAT, the payment-card testing platform you work on at Ayris Global. By the end you’ll be able to look at any codebase and draw its architecture from memory.

⏱ ~12 min · 🟢 Start here · Prerequisites: none

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

• Explain what “architecture” actually means, in plain words, to anyone
• Read and draw the five diagram types every engineer uses
• Trace a single click in a web app all the way down to a row in a database and back
• Look at the Assure PAT codebase and name every layer, every boundary, every table relationship
• Hold your own in a system-design interview using a repeatable framework

Before photo — what do you already believe?

Take this before you’ve learned anything. Getting these wrong is fine — that’s the point. We’ll re-test the same ideas at the end and you’ll see how far you moved.

1. What even is “system design”?

Here’s the whole field in one sentence:

The one-sentence definition

System design is the art of deciding what the pieces of a software system are, what each piece is responsible for, and how they talk to each other — so that the whole thing is correct, fast enough, and cheap enough to run and change.

That’s it. Everything else — databases, APIs, caches, queues, load balancers — are just pieces and ways for pieces to talk. Don’t let the jargon intimidate you. A senior engineer isn’t someone who memorised 50 buzzwords; it’s someone who can look at a problem and say “we need these four boxes, connected like this, because…” and be right about the “because.”

An analogy you already understand: a restaurant

You don’t need a CS degree to understand how a restaurant works, and a restaurant is a system:

flowchart LR
    Customer([Customer]) -->|orders| Waiter[Waiter]
    Waiter -->|ticket| Kitchen[Kitchen]
    Kitchen -->|reads recipe| Cookbook[(Cookbook)]
    Kitchen -->|gets ingredients| Pantry[(Pantry)]
    Kitchen -->|plated food| Waiter
    Waiter -->|serves| Customer

• The customer doesn’t walk into the kitchen — they talk to the waiter (a clean boundary).
• The waiter doesn’t cook — they pass a ticket to the kitchen (separation of responsibility).
• The kitchen reads recipes from a cookbook and pulls from a pantry (it depends on stored data).

Swap the words and you have a web application:

This single mapping is the spine of the entire track. Every page just zooms into one of these boxes.

2. The two questions architecture always answers

Whenever you see a system diagram, it is answering exactly two questions. Train yourself to ask them:

1. What are the boxes? (the components — the nouns: server, database, cache…)
2. What do the arrows mean? (the interactions — the verbs: “sends HTTP request”, “reads from”, “publishes event”…)

If you can name every box and explain every arrow, you understand the system. That’s the whole skill. Now let’s learn to read the arrows and boxes.

3. How to read diagrams (the part nobody teaches you)

Engineers communicate in pictures. There are five diagram types you’ll meet for the rest of your career. We’ll use all of them in this track, so let’s learn to read each one now. For each: what it’s for, how to read it, and a live example.

3.1 Boxes-and-Arrows (a.k.a. block / component diagram)

What it’s for: the big picture — what the major pieces are and who talks to whom. This is the most common diagram in the world.

How to read it: boxes are components; an arrow A → B means “A initiates a request to B” (A depends on B). Follow the arrows like roads.

flowchart LR
    Browser[🌐 Browser] -->|HTTPS| API[Express API]
    API -->|SQL| DB[(MySQL)]
    API -->|stores files| S3[(AWS S3)]

Read it aloud: “The browser talks to the API over HTTPS; the API talks to MySQL with SQL and stores files in S3.” If you can narrate a diagram in one sentence, you’ve read it correctly.

Convention: what the shapes mean

• Rectangle = a process / service / component
• Cylinder [( )] = a datastore (database, file store, cache) — it looks like a physical disk
• Rounded pill ([ ]) = an actor (a person or external system)
• Arrow direction = who starts the conversation, not which way data flows (data usually flows both ways)

3.2 Sequence diagram — the order things happen in

What it’s for: showing a single flow step-by-step over time. The killer diagram for “what happens when I click this button?”

How to read it: each vertical line is a participant. Time flows downward. Each horizontal arrow is one message/call. Read top to bottom like a comic strip.

sequenceDiagram
    participant U as User
    participant B as Browser
    participant A as API
    participant D as Database
    U->>B: clicks "Save"
    B->>A: PUT /selected-profiles
    A->>D: INSERT row
    D-->>A: ok
    A-->>B: 200 { added: [...] }
    B-->>U: shows "Saved ✓"

Solid arrow ->> = a call/request. Dashed arrow -->> = a response/return. We’ll use this exact diagram (with real data) on the Request Lifecycle page to dissect the profile-selection bug.

3.3 ER diagram (Entity-Relationship) — how data is shaped

What it’s for: the structure of a database — what tables exist and how they relate. Essential for reading any data model.

How to read it: each box is a table. Lines connect related tables. The symbols on the line ends (called crow’s feet) tell you “how many”:

erDiagram
    ORGANIZATION ||--o{ USER : "has many"
    ORGANIZATION ||--o{ PROFILE : "owns"
    PROFILE }o--|| ISSUER : "belongs to (optional)"
    ORGANIZATION {
        int id PK
        string name
    }
    USER {
        int user_id PK
        int org_id FK
        string email
    }

How to read crow’s-foot notation — memorise these 4

The symbol nearest a table tells you how many of that table participate:

• || → exactly one
• o| → zero or one (optional)
• }| → one or many
• }o → zero or many

So ORGANIZATION ||--o{ USER reads: “one organization has zero-or-many users; each user belongs to exactly one organization.” This is a one-to-many relationship — the bread and butter of databases. We dedicate a whole page to this.

3.4 Flowchart — decisions and logic

What it’s for: the path through a decision. Branches, loops, conditions. Great for “how does the system decide X?”

How to read it: diamonds are decisions (yes/no); rectangles are actions. Follow the labelled arrows out of each diamond.

flowchart TD
    Start([Request to select profile]) --> Q{Profile has an issuer?}
    Q -->|Yes| Save[Save selection ✓]
    Q -->|No| Resolve{Exactly one issuer<br/>for its brand?}
    Resolve -->|Yes| Auto[Auto-fill issuer] --> Save
    Resolve -->|No| Pick[Ask user to pick] --> Save
    Save --> End([Done])

This is literally the bug you and I debugged: when a profile had no issuer and the code didn’t resolve one, the selection silently failed. A flowchart makes the missing branch obvious.

3.5 The C4 model — zoom levels for big systems

What it’s for: describing a large system at different zoom levels, so you don’t drown in detail. C4 = four levels, but you’ll mostly use the first three:

The trick that makes senior engineers sound senior: they pick the right zoom level for the conversation. Planning a feature? Container level. Debugging? Component level. Talking to a customer? Context level. The Case Study page draws Assure PAT at all three.

4. The golden rule of reading any system

When you’re dropped into an unfamiliar codebase (which is every job, forever), follow the request:

The “follow the request” method

1. Find where a request enters (a route / URL).
2. Follow it inward: route → controller → service → database.
3. Watch it come back out: database → service → controller → response.
4. Draw the boxes you passed through. You now have the architecture.

We’ll do exactly this with a real Assure PAT request on the Request Lifecycle page. It’s the single most useful habit in this entire track.

Here’s a teaser of what “follow the request” looks like — step through one click as it travels Browser → DNS → Load Balancer → App Server → Cache → Database and back. Don’t worry about every box yet; just feel the shape of the journey. The Request Lifecycle page dissects each hop.

5. How this track is ordered (and why)

flowchart TD
    O[0 · Start Here] --> F[1 · Foundations]
    F --> L[2 · Layered Architecture]
    L --> D[3 · Data Modeling]
    D --> A[4 · APIs, Auth & Multi-Tenancy]
    A --> R[5 · Request Lifecycle]
    R --> S[6 · Scaling & Distributed Systems]
    S --> C[7 · Case Study: Assure PAT]
    C --> H[8 · How to Learn Fast]

    F -.->|build vocabulary| L
    D -.->|tables power| A
    R -.->|ties it together| C

• Pages 1–2 build the vocabulary and the layering idea.
• Pages 3–4 are the two pillars of any backend: how data is shaped and how it’s accessed safely.
• Page 5 ties everything together by tracing one real request.
• Page 6 adds the “make it big and fast” concepts.
• Page 7 is the capstone — the whole Assure PAT system, drawn out.
• Page 8 is about you: how to learn this faster and stick the landing in interviews.

Read them in order the first time. After that, each page stands alone as a reference.

6. How to actually study this (do this, don’t just read)

Reading ≠ learning

You will forget 90% of what you only read. You’ll keep what you do. For every page:

1. Read it once for the story.
2. Re-draw one diagram from memory on paper. If you can’t, re-read that section.
3. Open the real Assure PAT code and find the thing the page described. Seeing controllers/CardRequestController.js in the flesh cements it.
4. Explain it out loud to an imaginary beginner (the Feynman technique). Where you stumble is where you don’t actually understand yet.

The “How to Learn Fast” page at the end goes deep on this. But start the habit now.

Check Yourself

Cover the answers. Say each one out loud before you peek — retrieval is what makes it stick. This is the “after photo” for the quiz you took at the top.

Still Unclear?

Paste any of these into Claude to go deeper on the spots that didn’t land:

• “I’m a beginner backend dev. Explain the difference between a boxes-and-arrows diagram, a sequence diagram, and an ER diagram using a single example app — a to-do list. Show all three as text/mermaid and tell me what each one reveals that the others hide.”
• “Walk me through the ‘follow the request’ method on a tiny Express + MySQL app. Pick one route, show route → controller → service → database → response, and at each step tell me what file it would live in and what it’s responsible for.”
• “Quiz me on crow’s-foot ER notation. Give me 5 relationship statements in plain English and I’ll write the mermaid erDiagram line for each. Mark me and explain any I get wrong.”

Why AI Can’t Do This For You

AI can draw you a beautiful diagram of a system in seconds. What it can’t do is stand in front of your messy, undocumented codebase, follow the actual request, and decide which four boxes matter and why — that judgement only forms by tracing real code with your own hands. It also can’t pick the right zoom level for the room you’re in: a model will happily dump component-level detail on a customer who needed the context view. Reading and drawing architecture from memory is a muscle. Generate the diagram if you like, but you still have to verify it against reality — and verifying is the skill that gets you hired.

Module done? Add it to today’s tracker

Ready? Turn the page to Foundations — where we answer “what is a system, really?” and meet every building block you’ll ever use. 👉