Lesson 1 / 25

What NGINX Does and How It Works

Explain NGINX's roles and its event-driven architecture.

Web server, reverse proxy, load balancer

NGINX (pronounced "engine-x") is a high-performance web server, reverse proxy, load balancer and HTTP cache, created by Igor Sysoev and first released in 2004 to solve the "C10K" problem of handling ten thousand concurrent connections. Today it fronts a large share of the world's websites. Its speed comes from its architecture: a master process reads configuration and manages a small number of worker processes (typically one per CPU core), and each worker handles thousands of connections in a single-threaded, event-driven, non-blocking loop using the operating system's efficient event APIs (epoll on Linux, kqueue on BSD and macOS). Instead of dedicating a thread to each connection, a worker reacts to events ("data arrived", "socket writable") and moves on, so memory use stays low under heavy concurrency. NGINX Open Source is free; NGINX Plus (from F5) adds commercial features such as active health checks and an API for dynamic configuration. Forks such as Angie and freenginx also exist.

Master and workers

One master manages several workers; each worker multiplexes many connections with an event loop.

Figure 1.1 — The master process and event-driven worker processes.

NGINX in front of an application

A typical request path through NGINX.

browser --HTTPS--> NGINX (TLS, compression, static files, caching, rate limits)
                     |-- /assets/*  -> served from disk
                     |-- /api/*     -> proxied to app servers (load balanced)
                     '-- /ws        -> WebSocket upgrade proxied to realtime service

ps -ef | grep nginx
# expect one "master process" line and one "worker process" line per core
# when worker_processes is set to auto

NGINX is not your application server

NGINX excels at connections, TLS, static files and proxying. Your business logic runs in an application server (Node.js, Gunicorn, PHP-FPM, a Java service) behind it.

Quick check: How does an NGINX worker process handle many connections at once?

With a single-threaded, event-driven, non-blocking loop
By creating a new thread per connection
By forking a process per request
By queuing connections until one finishes

Answer

With a single-threaded, event-driven, non-blocking loop — Workers react to I/O events for thousands of connections without a thread per connection.