11. Putting it together — what happens when your .NET API handles a request

1. The network card receives packets → OS TCP/IP stack reassembles them → data lands in a socket buffer (kernel memory).
2. Kestrel (ASP.NET Core server), waiting asynchronously on that socket, is woken by an I/O completion; a thread-pool thread picks up the work.
3. Bytes are parsed into an HttpContext (objects allocated on the heap); middleware and your controller run — CPU executes JIT-compiled code, using stack frames for each method call.
4. Your code awaits a SQL query → the thread returns to the pool (no thread blocked); the request is sent through another socket to SQL Server.
5. SQL Server (its own process) checks its buffer pool in RAM; if the pages aren't cached it reads them from disk (slow), executes the plan, returns rows.
6. The continuation runs on a pool thread, serialises JSON, writes to the socket; the OS sends packets back.
7. Objects of the request become unreachable → collected later by the GC (most die in generation 0, very cheaply).

Every performance topic on DevLadder maps to one of these steps: CPU (algorithms), memory (allocations, GC), I/O (disk, database), network (latency, payload size), and threads (async, locking).