Understanding Nginx’s Core Concurrency Model: Multi‑Process, Event‑Driven, and Non‑Blocking I/O

Multi‑process Architecture

Nginx starts by creating two types of processes: a Master process that manages configuration, monitoring, and hot‑reloading, and multiple Worker processes that handle actual network requests. Each Worker runs on a separate CPU core, has its own address space, and is isolated by the operating system, which improves stability and fault tolerance because a crash in one Worker does not affect others.

This design also fully utilizes multi‑core CPUs, enabling true parallel processing.

Event‑Driven Architecture

The event‑driven model centers on an event loop that listens for and dispatches events such as incoming network requests, timer expirations, or file‑descriptor readiness. Callbacks or task queues process these events, avoiding the overhead of thread or process switches and making the model ideal for I/O‑bound workloads.

Its advantages include low resource consumption and strong concurrent handling capability, which is why it is widely used in high‑concurrency servers, GUI applications, and asynchronous frameworks like Node.js or libevent.

I/O Multiplexing

I/O multiplexing allows a single thread or process to monitor multiple I/O channels simultaneously. Common implementations include select, poll, epoll, and kqueue. The kernel tracks a set of file descriptors and notifies the application when one or more become ready, enabling efficient management of many connections with few threads and reducing context‑switch overhead.

Typical use cases are high‑concurrency network services, long‑lived connections such as instant messaging or proxy servers.

Non‑Blocking I/O

Non‑blocking I/O returns immediately from system calls without waiting for data, often yielding an EAGAIN error when no data is available. Combined with I/O multiplexing or an event‑driven loop, it enables responsive, scalable network services.

While it reduces thread count and avoids blocking, it increases programming complexity because developers must handle partial reads/writes, retries, and buffer management.