NGINX has its foundation in event-based architecture (EBA). In EBA, components interact predominantly using event notifications instead of direct method calls. These event notifications, occurring from different tasks, are then queued for processing by an event handler. The event handler runs in an event loop, where it processes an event, de-queues it, and then moves on to the next event. Thus, the work executed by a thread is very similar to that of a scheduler, multiplexing multiple connections to a single flow of execution. The following diagram shows this:

When compared with the thread-based architecture, EBA gives better performance output. In EBA, there are a fixed number of threads performing tasks and no new threads are formed. Thus, we achieve better utilization of the CPU and an improved memory footprint. There is also no overhead of excessive context switching and no need for a thread stack for each connection. Ideally, the CPU becomes the only apparent bottleneck of an event-driven application.

NGINX runs one master process and several worker processes. The master process reads/evaluates the configuration and maintains the worker processes. All request processing is done by the worker processes. NGINX does not start workers for every request. Instead, it has a fixed pool of workers for request processing. Each worker accepts new requests from a shared listen queue. The worker then uses the available event-notification interfaces, such as epoll and kqueue, to process each connection in an efficient event loop. The idea is to optimize the utilization of the server's resources using nonblocking/asynchronous mechanisms when possible. By doing so, each worker is able to process thousands of connections. The following diagram shows this:

NGINX has an extensible modular architecture. There is a core module (ngx_core_module), which is responsible for connection handling. Then, there are modules for every kind of processing that NGINX offers, for instance an HTTP module (ngx_http_core_module) for HTTP processing, an e-mail module (ngx_mail_core_module) for e-mail processing, a proxy module (ngx_http_proxy_module), and so on. The modular system is quite extensible and allows third-party developers to extend NGINX beyond its existing capabilities. Each worker loads a chain of modules as specified in the NGINX configuration. Every request that a worker handles goes through the loaded chain of modules.