How does NGINX's event-driven architecture work?

NGINX's event-driven architecture is what lets a handful of worker processes serve tens of thousands of connections without the overhead of one thread per client.

Each worker runs a single-threaded event loop. It registers all open sockets with the OS's efficient event notification interface, then blocks on a single call that returns only when one or more sockets have an event ready - such as data arriving, a connection closing, or a write buffer becoming free. The worker processes each ready event quickly and non-blockingly, then goes back to waiting.

Because no request blocks the worker while waiting on I/O, one worker can interleave work across many connections at once. CPU-bound work is the exception NGINX tries hard to avoid inside the main loop - operations like heavy regex processing or blocking disk access are minimized or offloaded, since they'd stall every connection that worker is handling.

flowchart TD
  A[Worker starts event loop] --> B[Register sockets with epoll/kqueue]
  B --> C[Block on event notification call]
  C --> D{Event ready?}
  D -- Yes --> E[Handle read/write for that connection]
  E --> F[Return control, no blocking]
  F --> C
  D -- No events yet --> C

This is why NGINX's memory and CPU usage stay flat as connection counts climb, in contrast to architectures where each connection carries the fixed overhead of its own thread or process.