The NGINX architecture
NGINX has its foundation in event-based architecture (EBA). In EBA, components 
interact predominantly using event notiffcations instead of direct method calls. These 
event notiffcations, 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 ffow of execution. The following diagram shows this:
When compared with the thread-based architecture, EBA gives better performance 
output. In EBA, there are a ffxed 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 conffguration 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 ffxed pool of workers for request processing. Each worker 
accepts new requests from a shared listen queue. The worker then uses the available 
event-notiffcation interfaces, such as epoll and kqueue, to process each connection 
in an efffcient 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: