A server that dedicates one operating-system thread to each open connection behaves fine at a few hundred clients but collapses somewhere in the tens of thousands. Concretely, what runs out, and why did that problem drive servers toward event-driven designs?

## The shape of the problem "C10K" is the shorthand for the observation, popularised around 1999–2003, that hardware of the day could easily push the bandwidth for ten thousand simultaneous clients, yet server *software* fell over long before that. The bottleneck was architectural, not physical: the dominant server model gave every connection its own thread (or process), and blocked that thread on every read. That design is beautifully simple. Each connection gets a straight-line procedure with local variables, a natural call stack, and ordinary sequential control flow; the operating system handles the interleaving. It fails only for one reason: it makes the unit of cost the *connection*, when the thing you actually want to pay for is the *work*. ## What actually runs out **Stack memory.** A thread needs a contiguous stack, sized for the deepest call chain it might ever take — historically a megabyte or more of reserved address space, with pages committed as touched. Ten thousand threads is a stack budget measured in gigabytes of reservation, and even the committed fraction (guard pages, top frames, thread-control structures) is hundreds of megabytes doing nothing. Modern connections are mostly *idle*: a keep-alive HTTP connection or a WebSocket may transfer nothing for minutes while holding its stack the whole time. **Scheduling entities.** Every OS thread is an object the kernel must track and place on run queues. Bookkeeping that is trivial at hundreds becomes significant at tens of thousands, and any operation proportional to the number of threads (accounting, signal delivery, some debugging or profiling paths) degrades. **Context-switch throughput.** This is the killer at scale. A switch costs on the order of a microsecond of direct work — save registers, swap stacks, change address-space bookkeeping — but the *indirect* cost is worse: the new thread's stack, heap objects and instruction footprint are cold in L1/L2 and in the TLB. When each wake-up does 200 bytes of parsing, the switch overhead can exceed the useful work by an order of magnitude. The machine reports high CPU utilisation while doing very little; throughput plateaus and then declines as concurrency rises, and latency variance explodes. **Thundering herds and lock convoys.** Thousands of threads contending for an accept path, a shared cache, or an allocator turn every shared structure into a contention point. Even with fine-grained locking, the sheer number of runnable threads amplifies queuing effects. ## Why event-driven designs fix it An event-driven server keeps a small number of threads — often one per core — each running a loop: ask the kernel which of the registered handles are ready, then run a short handler for each ready handle. Per connection you now store only a buffer and a small state object (a few kilobytes at most, sometimes a few hundred bytes), and you pay CPU only when bytes actually move. Cost scales with *events per second*, not with *connections*. Ten thousand idle connections become ten thousand entries in a kernel data structure and ten thousand small state records — no stacks, no scheduling entities, no switches. The trade is a real one. Straight-line code becomes a state machine: you cannot "just call read and wait", so control flow is chopped into callbacks, promises, or resumable coroutines. Any handler that blocks or runs long stalls every other connection on that loop, because there is no preemption inside a handler. Debugging is harder because a stack trace no longer shows the whole logical operation. These are the costs event-driven servers pay to make connections cheap. ## The modern qualification The arithmetic changes when threads stop being OS threads. Lightweight user-space threads — green threads, goroutine-style schedulers, fibers, virtual threads — give each connection a small growable stack (kilobytes, grown on demand) and multiplex many of them onto a few carrier threads, switching in user space without a kernel transition. Underneath, the runtime is still doing readiness-based multiplexing; it just hides it, restoring blocking-style code with event-loop-style costs. So the *pattern* thread-per-connection is no longer disqualifying — but thread-per-connection **on kernel threads** still is, and the reason it was disqualifying (cost tied to connections, not work) is exactly the reason those runtimes exist. ## Numbers worth carrying - OS thread stack reservation: often ~1 MB default, sometimes 8 MB; user-space thread: a few KB, grown on demand. - Context switch: roughly 1–10 microseconds all-in including cache effects; at 100,000 switches/second that is a meaningful fraction of a core. - Per-connection state in an event-driven server: typically a read buffer plus parser state — hundreds of bytes to a few KB. ## How to say it in an interview Name the resource (stacks, scheduling entities, switches, cache locality), state the scaling rule (cost per *connection* rather than per *unit of work*), and then say what event-driven buys and what it costs (state machines, no blocking allowed in handlers).