Checkpoint: Computer & OS Foundations

Introduction

You just spent nine lessons living inside a single machine — and it changed how you'll read every system for the rest of the course. Before we leave the single server behind, let's prove it stuck.

This checkpoint isn't about definitions. It's nine decisions — the exact judgment calls a senior engineer makes in a design review or an incident: which resource is the bottleneck? threads or an event loop? how big should the pool be? is that a race? Answer each on first instinct, the way you'd have to in the room, without scrolling back.

A miss isn't a failure — it's a signpost to the one lesson worth a five-minute revisit before the real distributed-systems work begins. Let's see what you can now do.

A recap board for the Computer and OS Foundations section: its nine mental models as a three-by-three grid of icon tiles forming one working model of a single machine — the anatomy of a request (NIC → kernel → socket → context switch → your code, the last step); the memory ladder (registers → cache → RAM → SSD → disk, where locality makes a small cache fast); access order (sequential beats random by ~100×); processes versus threads (isolation vs sharing); the ten-thousand-connections problem (one event loop holds thousands of idle sockets); connection pools (reuse beats re-open, small pool wins); concurrency versus parallelism (dealing-with vs doing-at-once); shared state and locks (close the read-modify-write gap); and the four bottlenecks (CPU, memory, disk, network — one saturates first and caps the server). A synthesis strip reduces it to one line: waiting wants concurrency, computing wants parallelism, sharing must be coordinated, and you fix one bottleneck at a time.

See It: The Checkpoint

Nine scenarios, one drawn from each lesson of this section. For each, pick the sharpest move — then see why, and which lesson it came from. Aim for seven of nine; anything lower just points you back to a quick revisit.

Nine scenarios from deep inside a single machine — decisions, not definitions. Answer on instinct, no looking back; each reveals which lesson it came from.

What You Can Now Do

Look back at the instincts you just installed — this is the whole section, in the shape of questions you can now answer cold:

Trace a request through the machine. A tap isn't magic — it crosses the NIC, the kernel stack, a socket, a context switch, and only then your code. You know where the time really goes.
Reason about the memory ladder. Registers → cache → RAM → SSD → disk span five orders of magnitude, and locality is why a small cache makes the whole system feel fast.
Respect access order. Sequential beats random by ~100× on disk (and matters even in RAM) — the physics under WAL, LSM trees, and Kafka.
Choose your unit of work. Processes for isolation, threads for shared-memory speed, an event loop for holding many idle connections, a small pool for a scarce downstream.
Tell concurrency from parallelism. Dealing-with vs doing-at-once — and the one question that decides which you need: is the work waiting or computing?
Defend shared state. You can spot a read-modify-write race and reach for the cheapest correct fix — a lock, an atomic op, or not sharing at all.
Name the death. When a server falls over, you know it ran out of exactly one of CPU, memory, disk, or network (or file descriptors, or context-switch budget) — and you diagnose before you spend.

That's not trivia. That's the working model of a computer that every distributed system is built on top of.

Key Takeaways

A computer is a small set of finite resources — cores, memory, disk, a network link — and almost every performance question is "which one is the constraint, and what's the cheapest way to relieve it?"
Waiting and computing are different problems. Waiting wants concurrency (event loops, async, holding connections cheaply); computing wants parallelism (more cores) — and mixing them up is behind most "why isn't this faster?" confusion.
Sharing is the source of both speed and danger. Shared memory makes threads fast and races possible; the discipline is to share as little mutable state as you can, and lock the rest carefully.
Every fix moves the bottleneck. Performance is a cycle: measure, find the one constraint, relieve it, measure again — and never optimize the resource that isn't the problem.

Next, the course makes its biggest leap. Everything so far has assumed one machine. But the moment you add a second — and then a thousand — a new universe opens: machines fail independently, disagree with each other, and can't even agree on the time. We step out of the single server and into distributed systems, starting with the first and most fundamental scaling decision: Scalability — Vertical vs Horizontal.