Complete CS Fundamentals Tutorial

There is a specific moment when fundamentals stop feeling academic. It is usually the first time a service falls over and the answer is not in the application code — the container was killed by the OOM killer, the connection pool exhausted because sockets sat in TIME_WAIT, the database ground to a halt on a lock nobody could see. None of those are framework problems, and no amount of framework knowledge solves them.

That is what this track is for. Operating systems, networking, database internals and compilers are not four separate subjects but four views of the same machine, and the engineers who debug hard problems quickly are the ones who can move between the views.

The latency numbers that shape every design

Orders of magnitude matter more than exact figures, and they explain most performance advice you will ever receive. The gap between a CPU cache hit and a cross-continent network round trip is roughly eight orders of magnitude — which is why caching works, why chatty APIs are slow regardless of how fast each call is, and why an N+1 query is fatal even when every query is 'fast'.

Processes, threads and the thing that actually blocks

A process owns an address space; threads share one. That single difference produces everything else: threads are cheap to create and can corrupt each other, processes are isolated and expensive to coordinate. Context switching between threads is cheaper than between processes, but neither is free — and a system spending more time switching than working is thrashing.

The concept that matters most in practice is blocking. A thread blocked on I/O consumes no CPU but does consume a thread, and threads are a bounded resource. That is the whole argument for async I/O: not that it is faster per operation, but that it lets one thread have thousands of operations outstanding. It is also why blocking inside an async runtime is so damaging — it removes a thread from a pool sized on the assumption that nothing blocks.

Networking: the four layers you will actually debug

The seven-layer model is a teaching device. In practice failures cluster into four questions, and asking them in order resolves most network problems faster than any tool.

Can it resolve? DNS, including caching and TTLs that keep a stale record alive after a cutover. Can it connect? TCP — routing, firewalls, security groups, a listener bound to loopback instead of all interfaces. Can it negotiate? TLS — certificate chain, expiry, hostname match, protocol and cipher overlap. Can it understand? HTTP — status codes, headers, timeouts, keep-alive.

Each layer has its own tool, and going in order stops you from debugging an application error that is really a DNS problem.

# 1. Resolution - and is anything caching an old answer?
dig +short api.example.com
dig +trace api.example.com | tail -5

# 2. Connection - can a TCP session be established at all?
nc -vz api.example.com 443
ss -tan | awk '{print $1}' | sort | uniq -c    # TIME_WAIT / CLOSE_WAIT counts

# 3. TLS - chain, expiry, hostname, negotiated version
openssl s_client -connect api.example.com:443 -servername api.example.com </dev/null \
  | openssl x509 -noout -subject -issuer -dates

# 4. HTTP - timing broken down by phase
curl -w '\ndns %{time_namelookup}  tcp %{time_connect}  tls %{time_appconnect}\
  ttfb %{time_starttransfer}  total %{time_total}\n' -o /dev/null -s https://api.example.com

A large stack of CLOSE_WAIT sockets means your application is not closing connections it was told to close — a file-descriptor leak that eventually exhausts the process limit. A large stack of TIME_WAIT is usually normal, and is the kernel doing its job after you closed.

Why database internals show up in application bugs

Three database concepts explain a surprising share of production incidents. Indexes are usually B-trees, which is why a query can use an index on (a, b) to filter by a or by a, b but not by b alone — the leftmost-prefix rule. Isolation levels decide which anomalies you can observe, and the default is rarely the strictest. Locking is where throughput goes to die, usually through transactions held open across a network call.

That last one is worth stating plainly, because it is the most common self-inflicted database outage: a transaction opened, an HTTP request made inside it, and every row it touched locked for the duration. Under load the lock queue grows faster than it drains and the database appears to stop.