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

Nginx is a widely used high‑performance web server whose efficiency stems from a well‑designed architecture. The architecture consists of modular design, an event‑driven model, multi‑stage asynchronous request processing, a master‑worker process model, and a memory‑pool mechanism.

Modular Design

Nginx’s core is minimal; everything else is implemented as modules. The official distribution defines five module types: core, configuration, event, HTTP, and mail. Core and configuration modules are tightly coupled with the framework, while the event module underpins the HTTP and mail modules, which focus on the application layer.

The configuration and core modules relate closely to the Nginx framework; the event module serves as the foundation for HTTP and mail modules, which focus on the application layer.

Event‑Driven Architecture

In an event‑driven architecture, events are generated by sources (e.g., network cards, disks), collected and dispatched by an event collector, and processed by registered event handlers (modules). Nginx’s event module performs the collection and dispatch, while any module can act as an event consumer after registering its interest.

Traditional web servers such as Apache handle events only for TCP connection establishment and teardown; after a connection is opened, processing proceeds sequentially, tying up resources until the connection closes. This leads to inefficient resource usage, as illustrated in the diagram.

Traditional web server event handling model (process shown as rectangle).

Nginx differs by using modules as event consumers; only the event collector/distributor occupies a process, invoking modules as needed. This design improves network performance and reduces request latency.

Nginx event handling model.

Multi‑Stage Asynchronous Request Processing

Requests are divided into several stages, each triggered by specific events. For static file requests, Nginx defines about seven stages that may repeat many times, allowing fine‑grained asynchronous handling.

Stages and triggering events for static HTTP request processing.

Each stage is processed when the corresponding event is dispatched; the next stage waits for the kernel to signal the next event (e.g., via epoll).

Master and Worker Process Design

After startup, Nginx runs a master process that manages multiple worker processes. The master handles signals, monitors workers, and can start/stop them, while workers handle client request events. Workers are equal peers; each request is processed by a single worker. The number of workers is typically set to the number of CPU cores.

On the server, the Nginx processes can be observed as shown.

Utilizing Multi‑Core Concurrency

Each worker runs on a separate CPU core, improving network throughput and reducing latency.

Load Balancing

Workers communicate via IPC to balance load, assigning new requests to less‑busy workers.

Master Process Supervision

The master process consumes minimal resources but can restart failed workers, support hot upgrades, and apply configuration changes, enhancing reliability and dynamic scalability.

Memory‑Pool Design

Nginx uses a simple memory pool to reduce fragmentation and the number of system calls. Each request gets an independent pool that is destroyed at the end of the request, returning memory to the OS in one operation, which lowers CPU usage and improves concurrency.

Author: JeffreyC https://segmentfault.com/a/1190000018261096