cld-toys › Guided exercises

Guided Exercises

Hands-on labs against real, full-strength systems — not reimplementations. You run real commands, in real terminals, and observe real behavior.

Each exercise runs against actual software (Postgres, Docker, Redis, Kafka) rather than a toy model of it. Every step is a predict → do → observe beat: you commit to a guess, run the command, then click to reveal the real terminal output and check yourself.

Every transcript here is real The output hidden behind each prediction prompt was captured from a live container before publishing — never invented or guessed. That's the whole point: your prediction has to be checkable against ground truth.

Available now

PostgreSQL

Transaction Isolation Levels

Walk two psql sessions up the ladder from READ COMMITTED to SERIALIZABLE, producing at each rung exactly the anomaly the next level exists to prevent — ending at write skew, which only SERIALIZABLE catches.

3 parts · two terminals · Docker + postgres:16

PostgreSQL

MVCC and Vacuum

An UPDATE is really an INSERT plus a tombstone. Watch a row physically move, a table triple in size without gaining a row, and one idle transaction stop vacuum from reclaiming anything at all.

6 parts · two terminals · Docker + postgres:16

PostgreSQL

Index vs. Sequential Scan

An index isn't a switch that makes queries fast — it's one of four access paths, chosen by counting pages. Watch the planner refuse an index and be provably right, then watch two queries return the same 5,000 rows for 30× different cost.

6 parts · one terminal · Docker + postgres:16

PostgreSQL

WAL and Crash Recovery

SIGKILL a running Postgres mid-write and watch it rebuild itself from the log — then discover the uncommitted rows are on disk too, and lose 35 transactions that already reported success.

5 parts · two terminals · Docker + postgres:16

PostgreSQL

Lock Contention

One session holds a row lock, another blocks — and pg_locks reveals it's waiting on a transaction ID, not a row. Ends in a real deadlock, detected and killed in front of you.

4 parts · two terminals · Docker + postgres:16

PostgreSQL

Query Planner Statistics

Every plan Postgres picks is a bet on a number it guessed. Watch the planner give the identical row estimate for 990,000 rows and 1,000 rows, then watch one stale statistic turn a 374 ms query into a 1270 ms one — without a character of the SQL changing.

5 parts · one terminal · Docker + postgres:16

PostgreSQL

Replication Lag

Write a million rows to the primary and watch the replica report a count of 1 — then discover it never counts up, it jumps. Freeze replay to see "durable on the replica" and "visible on the replica" as two different numbers, and make a COMMIT hang forever.

4 parts · two terminals · Docker + postgres:16 ×2

Coming next

The backlog, roughly in the order they're worth doing. Each names a real system, a concept, and the aha the finished write-up should produce.

Docker Namespaces in isolation — same processes, different PID view
Docker cgroup memory limits — OOM-killed by the kernel, not your code
Docker Union filesystem layers — why docker diff works
Docker Container networking — DNS resolves only within a shared network
Redis Eviction policies under memory pressure — LRU vs. LFU keep different sets
Redis RDB vs. AOF persistence — what each loses on kill -9
Redis Pub/sub delivery semantics — fire-and-forget vs. streams
Kafka Partition ordering — ordering holds per partition, not per topic
Kafka Consumer group rebalancing — watch partitions get reassigned
Networking DNS resolution chain — dig +trace down the hierarchy
Networking TLS handshake by hand — the steps a browser hides
Networking Load balancer algorithms — round-robin vs. least-conn under uneven latency
Elasticsearch Inverted index sharding — the fan-out visible in the profile
etcd Leader election — kill the leader, watch a new one win