Understanding Nginx’s Modular Architecture and Event‑Driven Design

1. Nginx Modular Design

Highly modular design is the foundation of Nginx architecture. The server is split into many modules, each responsible for a single function, following the principle of high cohesion and low coupling.

Core modules are essential for normal operation, providing error logging, configuration parsing, event‑driven mechanisms, process management, and other core functions.

Standard HTTP modules handle HTTP protocol parsing, port configuration, page encoding, response header settings, and related features.

Optional HTTP modules extend standard HTTP capabilities, enabling special services such as Flash media delivery, GeoIP request parsing, SSL support, and more.

Mail service modules support POP3, IMAP, and SMTP protocols for Nginx’s mail services.

Third‑party modules allow developers to add custom functionality like JSON handling or Lua scripting.

2. Nginx Request Processing Model

Nginx is a high‑performance web server capable of handling massive concurrent requests. It combines a multi‑process mechanism with an asynchronous non‑blocking model.

Multi‑process

When a client connects, the master process forks a worker process to interact with the client until the connection closes.

Using separate processes eliminates the need for locks, reduces lock‑related performance impact, simplifies programming, and isolates failures—if one worker crashes, others continue, and the master quickly spawns a replacement.

The downside is the overhead of creating processes and copying memory, which can degrade performance under heavy load.

Asynchronous non‑blocking

Each worker uses an asynchronous non‑blocking approach: after issuing an I/O operation, if the result is not immediately available, the worker proceeds to handle other requests. The client does not wait; when I/O completes, the worker is notified and resumes processing the original request.

3. Nginx Event‑Driven Model

The asynchronous non‑blocking mechanism relies on an event‑driven model composed of an event collector, an event sender, and an event processor.

The collector gathers I/O requests from workers, the sender forwards these events to the processor, which handles them. The processor uses multiplexed I/O methods such as select, poll, and epoll.

4. Nginx Architectural Design

Nginx uses a master/worker multi‑process model. After the master starts, it enters a loop to receive external signals, then forks worker processes, each running its own loop to receive and handle events.

It is recommended that the number of workers matches the CPU core count, avoiding excessive process creation and competition for CPU resources. Nginx also offers CPU affinity options to bind workers to specific cores, reducing cache invalidation.

For each request, exactly one worker handles it. The master creates listening sockets, then forks workers. All workers share the listening socket; before registering a read event, they compete for an accept mutex, and the winner registers the event and accepts the connection.

After accepting, the worker reads, parses, processes the request, generates a response, sends it to the client, and finally closes the connection.

During operation, the master and workers communicate via a unidirectional pipe based on sockets. The pipe carries commands and worker IDs; the master also uses signals for external communication. Workers can also communicate with each other through similar mechanisms, locating the target worker’s PID and sending commands via a dedicated channel.

5. Summary

This article provides an overview of Nginx’s overall architecture, including its modular design, multi‑process and asynchronous non‑blocking request handling, and event‑driven model, offering a solid foundation for studying the Nginx source code.