Bringing the pieces together
An event driven server combines the ideas from the rest of this set into one architecture. Non blocking sockets feed a readiness interface like epoll, an event loop dispatches ready events to fast handlers in the reactor style, and any blocking work is pushed to a thread pool so the loop never stalls.
Common structures
- A single loop per core model runs one event loop on each CPU, with connections sharded across loops, often using SO REUSEPORT so the kernel balances accepts
- A loop plus worker pool model keeps networking on the loop and offloads CPU heavy or blocking tasks to workers
- Handlers must be state machines, since a request may pause for IO and resume later rather than running top to bottom on one stack
What makes it fast
Because idle connections cost only descriptor state, one process can hold huge connection counts. The scarce resource becomes CPU time inside handlers, not threads. The golden rule is that nothing on the loop may block. Every potentially slow operation is either asynchronous or offloaded.
The tradeoff
Event driven code is harder to write than straight line blocking code. Logic is fragmented across callbacks or state machines, and one blocking mistake degrades every connection at once. The payoff is scaling to connection counts that thread per connection cannot reach.
Key idea
An event driven server multiplexes non blocking sockets through an event loop with fast non blocking handlers, offloading any blocking work so the loop never stalls.