Learning nginx - History, Core Architecture & Why Choose NGINX

#Introduction

Before writing your first directive, you need to know why NGINX exists and what makes it different. This Episode 1 breaks down the history, core architecture, and reasons NGINX is chosen by almost every major tech company.

Understanding the architecture isn't just theory. Later, when you configure worker_processes, pick a cache strategy, or decide whether NGINX should replace Apache, every one of those decisions is rooted in how NGINX processes connections. Let's start from the beginning of the story.

#The Birth of NGINX and the C10K Problem

#Origins in 2002

NGINX was created by Igor Sysoev, an engineer from Russia. At the time, his job involved managing web servers for very high-traffic websites, and he felt the existing web servers weren't efficient enough.

The core problem was known as the C10K Problem: how can a server handle 10,000 simultaneous connections with reasonable resources? Apache and similar servers struggled because each connection meant one process or one thread. NGINX was designed specifically to answer this challenge.

#Public Release and Adoption

NGINX was released to the public in 2004 with the name pronounced "engine-x". Its single focus: handle thousands of concurrent connections with minimal memory usage. Within a few years, NGINX became one of the most widely used web servers in the world, becoming the backbone of CDNs and large-scale internet services.

#NGINX Core Architecture

#Event-Driven, Asynchronous, Non-Blocking

The key to NGINX is its event-driven model. An event loop monitors thousands of connections at once without waiting for any single connection to finish. I/O is done asynchronously and non-blocking: one thread handles many connections, switching between them as new events arrive.

ps -ef | grep nginx

The output shows one nginx: master process and several nginx: worker process entries. This is the foundation of NGINX's design.

#Master Process and Worker Processes

NGINX consists of two types of processes:

• Master process: reads the configuration, manages worker processes, and handles signals like reload.
• Worker processes: handle all actual connections. Each worker runs its own event loop.

The number of workers usually follows worker_processes auto;, which makes NGINX adapt to the number of CPU cores. Connections are distributed evenly across workers through an internal load balancing system, using epoll on Linux or kqueue on BSD/macOS to monitor events on thousands of file descriptors at once.

To see the modules and features available in your NGINX build:

nginx -V

nginx -V shows the version along with every compiled module, including --with-stream for Layer 4 and --with-http_v3_module if you're using a build that supports HTTP/3.

#NGINX vs Apache HTTPD

#Process-per-Connection Model

Apache traditionally uses a process-per-connection approach (MPM prefork) or thread-per-connection (MPM worker). Every new connection means a new process or thread. When connections reach thousands, memory overhead and context switching skyrocket.

#Why NGINX Wins at High Concurrency

Here's a quick comparison:

• Apache creates new resources per connection; NGINX uses one thread for thousands of connections.
• NGINX's memory per connection is far smaller, so it survives high traffic on limited hardware.
• Apache excels at per-directory .htaccess flexibility; NGINX drops this feature for performance and requires centralized configuration.

That doesn't mean Apache is bad. For shared hosting with high flexibility, Apache is still a reasonable choice. But for high-performance web serving, reverse proxying, and load balancing, NGINX is almost always the better option.

#NGINX's Main Roles in the Industry

#Four Dominant Roles

NGINX is more than just a web server. In the industry, it's used for:

• High-Performance Web Server: serving static content like HTML, CSS, JavaScript, and images extremely fast.
• Reverse Proxy & API Gateway: hiding backend applications like Node.js, Go, Python, or Java behind a single entry point.
• Layer 4 & Layer 7 Load Balancer: distributing traffic to many backends via the stream module (L4) and upstream (L7).
• HTTP Cache & Media Streaming: caching responses and streaming video with HTTP Range and chunked techniques.

Even when NGINX only serves static files, the resource savings free up the application backend to handle the logic that really matters.

#Proof of Adoption

NGINX and its derivatives (like OpenResty and NGINX Unit) serve a large share of the world's top websites, including acting as the main entry point for CDNs and edge servers. Run curl -I https://example.com and look at the Server header — there's a good chance it says nginx.

#One Tool, Many Roles

Another advantage that makes NGINX dominant: everything lives in a single binary. You don't need to install separate tools for caching, reverse proxying, and load balancing. It all starts with a config as small as this:

worker_processes auto;
 
events {
    worker_connections 1024;
}

These two blocks are the seed of nearly every configuration we'll write throughout the series. An architecture that's efficient by design makes NGINX suitable for any role you give it.

#Conclusion

Episode 1 explained why NGINX exists: the answer to the C10K problem born from the hands of Igor Sysoev in 2002. The event-driven non-blocking architecture with one master and many workers lets it serve thousands of connections with minimal resources.

Key takeaways:

• NGINX was born in 2002 to solve the C10K problem (10,000 simultaneous connections).
• Its architecture is event-driven, asynchronous, and non-blocking.
• There's one master process and many worker processes processing events.
• NGINX wins at high concurrency compared to Apache's process-per-connection model.
• Its main roles: web server, reverse proxy/API gateway, L4/L7 load balancer, and cache/streaming.
• The worker model is best configured to follow the number of CPU cores.

In the next episode we'll break down the anatomy of the nginx.conf configuration file and directives — starting with the context hierarchy of main, events, http, server, and location, the syntax rules for simple and block directives, and modularizing configuration with the include directive.