Why Nginx’s Modular, Event‑Driven Architecture Powers High‑Performance Servers

Preface

While reading a book on Nginx, I took notes to summarize its core architectural concepts.

Overall Architecture Overview

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

Modular Design

The foundation of Nginx’s architecture is its high degree of modularity. Apart from a small core, everything else is implemented as a module.

Nginx officially defines five module categories: core, configuration, event, HTTP, and mail modules. The relationships among them are illustrated below.

Among these, the core and configuration modules are tightly coupled with the Nginx framework, while the event module underpins both the HTTP and mail modules. The HTTP and mail modules operate at the application layer.

Event‑Driven Architecture

In an event‑driven model, events are generated by sources (e.g., network cards, disks), collected and dispatched by an event collector, and then processed by registered event handlers.

For Nginx, the event module gathers events from the NIC and disk, then distributes them to modules that have registered interest. Each module acts as an event consumer.

Traditional web servers like Apache treat events mainly as TCP connection establishment and teardown. After a connection is established, subsequent processing follows a sequential, blocking model, causing each request to occupy a process or thread for its entire lifetime, which wastes resources.

Nginx’s event‑driven approach differs: only the event collector/distributor occupies process resources, while modules are invoked briefly to handle specific events. This design reduces latency and improves throughput, provided that modules remain non‑blocking.

Multi‑Stage Asynchronous Request Processing

Multi‑stage asynchronous processing builds on the event‑driven model by dividing a request’s lifecycle into several phases, each triggered by specific events.

When serving a static HTTP file, the request passes through seven distinct phases, as shown below. These phases can repeat many times for large or unstable transfers, resulting in hundreds of phase executions for a single download.

Each phase corresponds to an event; after a module finishes handling its event, the kernel notifies Nginx (e.g., via epoll) that the next event is ready, allowing the next phase to proceed.

Master and Worker Process Design

Upon startup, Nginx creates one master process and multiple worker processes. The master process manages workers—handling signals, monitoring status, and spawning or restarting workers. Worker processes handle client request events. Workers are equal peers; each request is processed by a single worker, typically matching the number of CPU cores.

Advantages of this design:

Utilizes multi‑core concurrency: each worker runs on a separate CPU core, boosting network performance and reducing latency.

Load balancing: inter‑process communication distributes incoming requests to the least‑loaded worker.

Robust management: the master process can restart failed workers, perform graceful upgrades, and apply configuration changes without downtime.

Memory‑Pool Design

To avoid memory fragmentation and reduce system calls, Nginx employs a simple memory‑pool mechanism. Each request gets its own lightweight memory pool, which is allocated once and released in bulk when the request finishes.

This reduces CPU overhead, eliminates the need for modules to free individual allocations, and improves memory utilization and the maximum number of concurrent connections.