5 Ways to Improve Your Server-side Architecture with NGINX - FullStackMastery
  • Home  / 
  •  /  5 Ways to Improve Your Server-side Architecture with NGINX
By Jim Liao / June 17, 2017

I am currently using NGINX for our production systems and I have highly recommend it to everyone. NGINX is a HTTP server that is similar to the well-known Apache HTTP Server, but NGINX can do some awesome things better than Apache HTTP Server can. Below are the 5 awesome things you do with NGINX.

In this article, I assume you are familiar with basic web server workings and terminologies.

1. Virtual Hosting

Virtual Hosting is the ability to host multiple websites on the same operating system using only one HTTP server. There are two types of virtual hosting, IP and named virtual hosting. IP virtual hosting is the binding of a website domain or subdomain to a single IP address.

Something that I found more useful is the use the named virtual hosting, which allows you to share the same physical IP address across multiple website domains and subdomains. Named virtual hosting is a very handy feature as most web hosting providers do charge extra money for additional IP addresses.

2. HTTP Reverse Proxy

A reverse proxy is a server that sits in front of another web/application server in order to hide the backend application server from the client. The backend application server does not need to be hosted on the same machine as NGINX. In a standard reverse proxy configuration, NGINX acting as the reverse proxy is assigned a public IP address and standard port such as 80 for HTTP and 443 for HTTPS. As a reverse proxy, NGINX will forward all incoming HTTP requests to the backend application server which does not need to be on a standard port or public IP address.

Reverse Proxy


As an example, you can have a Java application server which will handle a subset of the requests running on a non-standard port such as 8800 on linux machine. NGINX can be located on the same linux machine or a separate linux machine which will be configured to listen on port 80 to forward all incoming traffic from port 80 to port 8800 of the application server. In this scenario, we are abstracting the Java application server from the clients. This affords us the ability to migrate the Java application server from one machine to another without having to update the client’s configuration of which host to connect to. As long as hostname of the NGINX server does not change, the traffic routing changes are instantaneous.

NGINX Reverse Proxy with Multiple Servers

You can see the biggest benefit of introducing reverse proxy into your architecture when you realize that DNS no longer needs to be updated on a server migration. Without using reverse proxy, when a server migration occurs, you have to update the IP address that is bind to the hostname of the server. DNS changes can take minutes or hours to propagate the configuration changes to all the clients. With a reverse proxy setup, you can simply update the configuration of NGINX to route the requests to a different server and this will dramatically reduce your service downtime.

3. HTTPS Reverse Proxy

Using NGINX as a reverse proxy is great, and more awesome is configuring NGINX as an HTTPS reverse proxy. This will avoid the inconvenience, labor and money of configuring all you application servers with SSL certificates. Using NGINX as a HTTPS reverse proxy, you no longer need to configure your application server with HTTPS. If you are unable to configure your application server with HTTPS, using NGINX is an awesome approach to keeping your communications secure between the client and server. Keep in mind that the communication between NGINX and application server is still using HTTP and is not secure. Therefore it is advise to run both servers on the same machine using the loopback TCP connection in order to keep the communication secure from the client all the way to the application server.

NGINX HTTPS Reverse Proxy

4. Load Balancing with NGINX

Load Balancing make your server architecture more scalable by distributing incoming traffic across a group of backend servers.

Once you have configured NGINX as a reverse proxy, you can also have it forward the HTTP requests to multiple backend servers configured as a server cluster. Each backend server within a cluster can be configured with a weighting which determines how frequency of requests that NGINX will route to that backend server. By default, each backend server has equal weighting. Having multiple backend servers will provide redundancy as well as the ability to spread the requests across multiple backend servers to reduce the stress on each server. A backend server can become unresponsive due to it being taken offline for maintenance, networking failures, or outright crashes. Regardless of the cause, NGINX will route the HTTP requests to the remaining backend servers within the configured cluster.

NGINX Load Balancing

Load Balancing Methods

The Round Robin Method

The most straightforward and popular load balancing strategy is using the round robin method. In round robin, the first server on the list is dispatched to the first client request, the next request is dispatched to the next server on the list until the last server is reached. The sequence is repeated with the first backend server.

The IP Hash Method

In some cases, the backend servers maintain state in the form of a user session. This can be problematic for load balancing when the HTTP requests reach backend servers which do not have a copy of the user session. One solution is to store the user session on a central location such as using memcached. Another solution is to actively replicate the user sessions across all backend server within the cluster.

Fortunately, NGINX also provides its own solution in the form of client IP hashing. Using the client’s IP and a hashing algorithm, the HTTP requests from a specific IP will always be sent to a mapped backend server. Only when a backend server becomes available will the routing be remapped. Using NGINX is the most straightforward configuration when dealing with user sessions. Other solutions will requires installing another server software or a replication library which can introduce more points of failures.

The Sticky Method

The sticky method enables session affinity, which causes client requests from the same client to be passed to the same server in the cluster. The guarantee backend server information is stored in a client-side cookie. NGINX can determine which server to distribute the client request to by inspecting the cookie information passed along with the request.

The Least Connection Method

If state does not need to be considered, then the least connection is a optimal approach for load balancing. Different requests take different amount of time to complete, hence the amount of outstanding requests could be different for each backend server. The least connection method will take into consideration the amount of outstanding requests and make sure none of the backend server are not overloaded with long running requests. In addition, this method will guarantee that faster and more powerful backend server will process more client requests than slower servers.

5. Content Caching

Content caching is a performance strategy where a cached version of a previously generated response is used instead of requiring a backend server to process the request and generate a response. Content caching is mainly used for static content such as images, but it can also be used to cache dynamic content which does not need to be refreshed in real-time.

NGINX can be enabled for content caching, which can be used to offload work from your backend server. Using content caching can also alleviate the backend software from implementing their own content caching strategies.

The Time to Live (TTL) of a cached response is controlled by the http proxy cache directive from the response message. By default, NGINX will only cache content of the response message when the proxy cache directive is specified. NGINX can be configured to always cache content regardless of this directive.

Content caching as a fault tolerant strategy

A great use we found for content caching is to configure NGINX to return the cached version of contents when the backend server is unavailable. This strategy can be used for RESTful web services in which the URI points to an immutable resources.


NGINX is an awesome piece of server software and I highly recommend you incorporate it into your backend services architecture. I just listed 5 awesome things above that you can use to improve the scalability or add redundancy to existing architectures.

Contact me if you need help in improving the scalability or redundancy of your existing server architectures. My team and I are ready to help your business with configuring, maintaining or troubleshooting your NGINX installation.

Click here to add a comment

Leave a comment: