Nginx Architecture Overview: Modular Design, Event‑Driven Model, Multi‑Stage Asynchronous Processing, and Master‑Worker Process Management

This note records my recent reading of Nginx‑related books and presents a concise overview of the server's high‑performance architecture.

Nginx achieves its speed through a combination of modular design, an event‑driven core, multi‑stage asynchronous request processing, a master‑worker process model, and an efficient memory‑pool mechanism.

Modular Design – Apart from a small core, every feature in Nginx is implemented as a module. The official distribution defines five module categories: core, configuration, event, HTTP, and mail. The relationship among these modules is illustrated below:

Configuration and core modules are tightly coupled with the Nginx framework, while the event module underpins both HTTP and mail modules, which focus on application‑level functionality.

Event‑Driven Architecture – Events are generated by sources such as network cards or disks, collected and dispatched by an event module, and then processed by interested modules that have registered for those events. Unlike traditional web servers (e.g., Apache) that handle only connection‑establishment events and then process requests in a blocking, per‑process manner, Nginx keeps the event loop lightweight and non‑blocking.

Traditional server model:

Nginx event‑driven model (events are dispatched to modules, not processes):

This design ensures that event consumers are invoked only briefly, preventing blocking and improving latency and throughput.

Multi‑Stage Asynchronous Request Processing – Built on the event‑driven core, a request is split into several stages, each triggered by specific events. For a static‑file HTTP request, Nginx defines seven stages, which may repeat many times depending on network conditions.

Master and Worker Process Design – Upon startup Nginx creates one master process and multiple worker processes. The master handles signals, monitors workers, and performs graceful upgrades, while workers independently handle client requests. The number of workers is typically set to match CPU cores.

The master‑worker model brings three main benefits: (1) full utilization of multi‑core CPUs, (2) built‑in load balancing via inter‑process communication, and (3) reliable process supervision that enables hot reloads and fault tolerance.

Memory‑Pool Design – To avoid fragmentation and reduce system calls, Nginx allocates a simple memory pool per request (or per TCP connection). The pool is released in one operation when the request finishes, lowering CPU overhead, improving memory utilization, and increasing the maximum number of concurrent connections.

— END —