Journeys
“What actually happens when I…?” Each journey starts as four boxes and lets you peel abstraction layers away until you reach the kernel, the NIC and the hardware. Every node is clickable: what happens, what state changes, how it fails, and the lesson that explains it.
The canonical interview question, taken seriously: from the URL bar through DNS, TCP or QUIC, TLS and HTTP, across routers to a load balancer and a backend — and at the deepest level, through both kernels. Zoom in until nothing is magic.
A "simple" query is a network round trip, two kernels, a query planner, a buffer pool, a B+ tree and — on a cold cache — an SSD read. Zoom in to see why the same query is 0.2 ms one moment and 40 ms the next.
One `read()` call is a privilege switch, a descriptor lookup, a file-system mapping from offset to block, a page-cache check, and — on a miss — an SSD command and a DMA transfer while your thread sleeps. Zoom in to see why the second read of the same file is a hundred times faster.
An allocation usually never reaches the OS: a runtime allocator carves it out of memory it already holds. When it does need more, the OS hands out virtual pages that cost nothing until first touch, when a page fault finally assigns physical RAM. The three runtimes route the same request very differently.
The shell forks itself, the child replaces its body with your executable, the loader builds an address space from the file’s segments, links shared libraries, sets up a stack and a heap, and the scheduler eventually puts the process on a core. Zoom in to see where a `Segmentation fault` at startup can actually come from.
The together journey: one `send()` through the socket API, the kernel’s socket buffer, the transport, IP, the device queue and the NIC — across the network — and the mirror image on the receiving host up to a thread waking in `recv()`. It is the reason OS and Networking are taught as one map.