The connected map

Operating Systems and Networking are not isolated courses. The same idea travels: a DSA queue becomes a scheduler queue, a socket buffer, a message queue and an async architecture; virtual memory becomes an OS page, a database page and a buffer pool. This page is the map — every arrow is a real mechanism, not a slogan.

Engineer Atlas

The platform’s domains, and where these two sit.

Engineer Atlas
│
├── DSA
├── Software Design
├── Database Engineering
│   └── Database Internals
├── Software Architecture
├── System Design
├── Operating Systems
├── Computer Networking
├── Distributed Systems
└── Agentic Engineering

One idea, many domains

Follow a single concept across the map.

Queue → ready queue → network buffer → message queue → async architecture

Queue (FIFO)DSA
↓
Scheduler ready queueOperating Systems
↓
Socket and NIC buffersNetworking
↓
Message queue / brokerSoftware Architecture
↓
Async, backpressured architectureSystem Design

Virtual memory → OS page → database page → buffer pool → database performance

Virtual memoryOperating Systems
↓
OS page and page cacheOperating Systems
↓
Database page (8 kB, slotted)Database
↓
Buffer poolDatabase
↓
Database performanceDatabase

Socket → TCP → HTTP → API gateway → backend → system design

Socket (descriptor + buffers)Operating Systems
↓
TCP connectionNetworking
↓
HTTP requestNetworking
↓
API gatewaySoftware Architecture
↓
Backend serviceSoftware Architecture
↓
System design: connections as a budgetSystem Design

Process isolation → containers → cloud infrastructure → agent sandbox

Process isolation (address spaces, namespaces)Operating Systems
↓
Containers (cgroups, layered FS)Operating Systems
↓
VMs and cloud infrastructureCloud
↓
Agent sandbox (least-privilege tools)Agentic

DSA → Operating Systems

The data structures you implemented for interviews are the data structures the kernel is built from — with concurrency, hardware and failure added.

DSA		Operating Systems	The actual mechanism
Queue	→	Scheduler ready queue	Runnable threads wait in per-core run queues; a FIFO gives round-robin, and Linux’s CFS/EEVDF replaces the FIFO with a red-black tree keyed by virtual runtime so the least-served thread is always at the leftmost node.
Graph cycle detection	→	Deadlock detection	Threads and locks form a wait-for graph: an edge from a thread to the lock it wants and from a lock to the thread that holds it. A cycle in that directed graph is a deadlock, and DFS with colouring finds it — exactly what database lock managers run periodically.
LRU cache	→	Page replacement and the page cache	When physical memory is full the kernel must evict a page; true LRU would need a timestamp update on every memory access, so the kernel approximates it with reference bits and active/inactive lists (the clock algorithm) — an LRU you can afford at hardware speed.
Heap / priority queue	→	Priority scheduling and timers	A scheduler that must always pick the highest-priority runnable task, and a kernel that must fire the earliest of a million timers, both need "extract-min in O(log n)" — a heap, or a timing wheel when the keys are bounded.
Stack	→	Call stack and stack frames	Every function call pushes a frame (return address, saved registers, locals) onto a per-thread region that the CPU’s stack pointer tracks; the LIFO discipline is why recursion works and why unbounded recursion ends in a guard page and `SIGSEGV`.
Hash table	→	Page tables and descriptor tables	A page table maps virtual page numbers to frames — a multi-level radix tree because the key space is 2^36 pages, with the TLB as a small hardware hash cache in front. The descriptor table is the simpler case: a per-process array indexed by fd, which is why "too many open files" is an array being full.

DSA → Networking

Routers, load balancers and TCP are running your data structures at line rate.

DSA		Networking	The actual mechanism
Trie / prefix structures	→	Routing lookup (longest-prefix match)	A routing table is a set of prefixes like `10.0.0.0/8` and `10.1.0.0/16`, and the rule is "the most specific match wins". A binary trie over the address bits answers that in at most 32 or 128 steps; hardware routers compress it into multi-bit tries or TCAM to do it in nanoseconds.
Hashing	→	Connection tables and load balancing	A NAT device and a stateful firewall look up every packet by its 4-tuple in a hash table of connections; an L4 load balancer hashes the same tuple to pick a backend so all packets of a flow land on the same server, and consistent hashing keeps most flows in place when a backend leaves.
Graphs	→	Network topology and routing protocols	The internet is a graph of autonomous systems; OSPF runs Dijkstra over link costs inside a network, while BGP is a path-vector protocol that chooses by policy, not shortest path — which is why the "shortest" route across the internet is rarely the one taken.
Queues	→	Network buffers	Every NIC ring, router output port and socket buffer is a bounded queue; when arrival rate exceeds departure rate the queue fills, latency grows with queue depth (bufferbloat), and then the queue drops. Queueing theory, not bandwidth, explains most tail latency.
Sliding window	→	TCP windows	TCP keeps a window of sent-but-unacknowledged bytes that slides forward as ACKs arrive; the window size (`min(cwnd, rwnd)`) bounds bytes in flight, so throughput is at most window ÷ RTT — the same two-pointer invariant you used for subarray problems, applied to a byte stream.

Database → Operating Systems

A database is a user-space program that re-implements half an operating system — pages, a buffer pool, a log — on top of the other half.

Database		Operating Systems	The actual mechanism
Database page	→	OS page cache and storage I/O	The database reads 8 kB pages with `pread()`; unless it opened the file with `O_DIRECT`, the kernel caches the same page in its page cache, so a "cold" database read may be a memory copy and a hot one may be double-cached. Storage I/O only happens when both caches miss.
Buffer pool	→	Memory management	The buffer pool is the database’s own page replacement: a fixed pool of frames, a hash from page id to frame, a clock-sweep eviction policy and dirty-page writeback — the same problem the kernel’s page cache solves, done in user space so the database controls what stays resident.
Write-ahead log	→	File I/O and fsync	A commit is durable only when the WAL record reaches the disk platter or flash, and `write()` merely copies into the page cache — so every commit ends in `fsync()`/`fdatasync()`, which is why commit latency is a storage-device number (~100 µs on NVMe, ms on cloud disks) and why disabling fsync "makes it fast".
Database connection	→	Socket and file descriptor	Each client connection is a TCP socket — a descriptor in both processes — and on PostgreSQL also a backend process with its own memory. "Too many connections" is a descriptor limit, a process limit and a memory limit at once, which is why pools exist.
VACUUM / compaction	→	I/O scheduling	Vacuum and LSM compaction rewrite large amounts of data in the background; they compete with foreground queries for the same device queue, so a compaction burst appears to users as query latency. Rate limiting them is I/O scheduling done by the database because the kernel cannot tell the two apart.

Database → Networking

Every distributed-database guarantee is a statement about what the network can and cannot do.

Database		Networking	The actual mechanism
Replication	→	TCP and network latency	Streaming replication ships WAL over one TCP connection; synchronous replication makes every commit wait for the replica’s acknowledgement, so commit latency includes an RTT — 0.5 ms across a rack, 2 ms across zones, 80 ms across the Atlantic.
Distributed database	→	Partial network failure	A partition is not "the network is down": some nodes can reach each other and some cannot, and every node must decide without knowing which side it is on. Quorums, leases and fencing tokens exist because TCP timeouts cannot distinguish a slow peer from a dead one.
Replica lag	→	Bandwidth + latency + processing	Lag is the sum of three delays: the WAL must be transmitted (bytes ÷ bandwidth), it must cross the path (RTT/2), and the replica must apply it (single-threaded on many engines). A burst of writes saturates bandwidth first, then the replay thread — and a read-your-writes bug follows.
Connection pooling	→	Handshake cost	A new database connection is a TCP handshake (1 RTT), a TLS handshake (1 RTT), authentication (1+ RTTs) and server-side setup — tens of milliseconds and a new process or thread. A pool amortises that once, which is why per-request connections collapse under load.

Software Architecture → Operating Systems

Architecture boxes are processes, threads and signals once they are deployed.

Software Architecture		Operating Systems	The actual mechanism
Worker pool	→	Threads and processes	A pool of N workers is N threads (shared memory, one crash kills all) or N processes (isolated, IPC needed). The right N is bounded by cores for CPU work and by memory per worker for I/O work — and Python’s GIL makes the choice for you.
Background jobs	→	Scheduling and I/O	A background job competes with request handlers for the same cores and the same disk; without `nice`, cgroup CPU shares or I/O rate limits, a nightly export makes the API slow while every dashboard says "utilisation 60%".
Containers	→	OS isolation	A container is a process tree with its own namespaces (PID, network, mount) and cgroup limits, sharing the host kernel. Isolation is a kernel feature, not a virtual machine — so a kernel bug or an unrestricted capability crosses the boundary.
Graceful shutdown	→	Signals	The orchestrator sends `SIGTERM`, waits a grace period, then `SIGKILL`. A handler must stop accepting, finish in-flight requests, close sockets and flush buffers within that window; `SIGKILL` cannot be caught, so anything not yet written is lost.

Software Architecture → Networking

Every arrow on an architecture diagram is a connection with a handshake, a timeout and a failure mode.

Software Architecture		Networking	The actual mechanism
API gateway	→	HTTP and TLS termination	The gateway terminates the client’s TLS session, parses HTTP to route by path and headers, and opens its own connections to services — so the backend sees the gateway’s IP, not the client’s, and every request crosses two TCP connections.
Load balancer	→	TCP and routing	An L4 balancer forwards TCP segments by rewriting addresses (or by DSR, changing only MACs) and must keep the whole flow on one backend; an L7 balancer is a full proxy with two TCP connections per request. Health checks are just more connections, on a timer.
CDN	→	DNS and edge networking	The CDN’s authoritative DNS answers with the address of an edge near the resolver (or one anycast address routed by BGP to the nearest POP). The edge terminates TLS with your certificate and serves from cache, so a cache hit never crosses an ocean.
WebSocket architecture	→	Persistent TCP/QUIC-based communication	A WebSocket is an HTTP request upgraded into a long-lived TCP connection; every idle connection still owns a socket, two kernel buffers and a load-balancer table entry, and NAT devices drop it after minutes of silence unless pings keep it alive.

System Design → Networking

System-design answers are only as good as the OS and networking facts underneath them. Each of these interview moves has a mechanism.

System Design		Networking	The actual mechanism
"Add a load balancer"	→	How traffic reaches and passes through it	Clients reach the balancer via DNS (several A records, or one anycast address); it holds a connection per client and, if L7, one per backend request. It is a single point of failure with its own capacity — connection table size, TLS handshakes per second — and its own network position.
"Handle 100K connections"	→	What each connection consumes	Each connection is a descriptor, ~8–64 kB of kernel socket buffers, a TLS session, and — in a thread-per-connection server — a thread with an 8 MB stack reservation. 100K connections is feasible with `epoll` and a few worker threads, impossible with 100K threads.
"Multi-region"	→	Latency and failure across regions	Regions are 30–150 ms apart, which puts synchronous cross-region calls out of any request budget; and they fail partially — a partition between regions leaves both alive and disagreeing. The design question is which writes may wait an RTT and which side wins a partition.
"Add a cache"	→	Page cache vs application cache vs CDN	Three different caches: the kernel’s page cache (free, transparent, per machine), an application cache such as Redis (a network round trip, shared, needs invalidation), and a CDN (edge, HTTP-level, TTL-driven). "Add a cache" without naming which is not a design decision.

Agentic → Operating Systems

An agent is a program that makes network calls and runs other programs. Both halves are OS and networking mechanisms with model-shaped costs on top.

Agentic		Operating Systems	The actual mechanism
Model API call	→	DNS → TLS → HTTP → network latency	Every model call is a DNS lookup (cached), a TLS-secured HTTP/2 stream on a pooled connection, and then seconds of streamed response; the first token’s latency is RTT plus provider queueing, so an agent loop of 20 calls is a minute of mostly waiting on sockets.
Tool execution	→	Process and container	A tool that runs a shell command is `fork`/`exec` of an untrusted program with the agent’s credentials, descriptors and network; it must be given a timeout (`SIGTERM`, then `SIGKILL`), a working directory, and captured stdout/stderr pipes that are drained so it cannot block on a full pipe.
Agent sandbox	→	OS isolation	Least privilege for tools is implemented with OS primitives: a separate user, namespaces and cgroups (a container), seccomp filters on system calls, a read-only filesystem, and a network namespace with no route out — or a microVM when the kernel itself is the trust boundary.
Long-running agent	→	Scheduling + queues + network	An agent that runs for minutes is a background job: it lives in a queue with retries and a budget, holds open sockets to providers across scheduler time slices, and must survive its worker being preempted, rate-limited or restarted mid-loop.