phase 0 · 0.1-backend-mental-model

What is a backend? (concepts only)

review intervals 3d 7d 21d 60d drills http-status-match

┌──────────┐        HTTP request         ┌─────────────┐
│          │  ─────────────────────►     │             │
│  CLIENT  │     (browser, phone, curl)  │   SERVER    │
│          │  ◄─────────────────────     │             │
└──────────┘        HTTP response        └──────┬──────┘
                                                │
                         ┌──────────────────────┼──────────────────────┐
                         ▼                      ▼                      ▼
                    ┌─────────┐           ┌─────────┐           ┌───────────┐
                    │DATABASE │           │  CACHE  │           │   QUEUE   │
                    │(Postgres│           │ (Redis) │           │  (NATS)   │
                    │ SQL)    │           └─────────┘           └───────────┘
                    └─────────┘

What is a backend?

In one sentence: a backend is the machine (or fleet of machines) that answers requests from apps and browsers, stores state that outlives any one user, and coordinates work that shouldn't happen on the user's device.

When you click "buy" on Amazon, your browser sends an HTTP request to a server owned by Amazon. That server reads some data from a database ("is this item still in stock?"), writes some data ("add it to this user's cart"), maybe talks to a payment API, and sends back an HTTP response. Everything that happens between the click and the "order placed" page is the backend's job.

The rest of this curriculum is about how backends do that job well — reliably, quickly, and without falling over when a million people click at once.

The vocabulary you need before anything else

HTTP — a text-based request/response protocol. "GET me this page", "POST this data." Every web API speaks it. It runs on top of TCP.
TCP — the reliable byte-stream protocol underneath HTTP. Handles ordering and retransmission so HTTP doesn't have to.
DNS — the phonebook that turns example.com into an IP address. Every request starts with a DNS lookup.
Port — a number (0–65535) that lets one IP host many services. HTTP traditionally uses 80, HTTPS 443.
JSON — the text format most APIs use in request/response bodies. Key-value pairs plus arrays.
Stateless — a server that doesn't remember you between requests. The HTTP protocol itself is stateless; servers add cookies or tokens to fake a memory.
Database — durable storage for structured data. Survives the process dying.
Cache — fast but volatile storage. Trades durability for speed.
Queue — a list of messages producers add to and consumers pull from. Used to decouple services that don't need to talk synchronously.

Why this task has no code

Every other task assumes this vocabulary. If backend is a fuzzy noun to you right now, Phase 1's goroutines and Phase 3's Redis distributed lock will feel like dark magic. Spend a day drawing the diagram above from memory. Trace the "user clicks buy" path three times, once per primitive. The test isn't a Go test — it's whether you can explain each hop in one sentence to a non-technical friend.

When that feels comfortable, run go-dojo placement phase-0 to self-assess, then move on.

Mastery criteria

- Draw the client/server request/response diagram from memory
- Explain in two sentences each: HTTP, TCP, DNS, port, JSON, stateless, database, cache, queue
- Given a concrete scenario ("user clicks 'buy'"), trace the request end-to-end through client → HTTP → server → DB, naming each hop

Verify

Run from your go-dojo repo root:

go-dojo verify 0.1-backend-mental-model

This runs the task's go test suite in exercises/phase-0/0.1-backend-mental-model/, commits the attempt to .go-dojo/attempts/, and updates your mastery.