Why You Can’t Rely on Tomcat Alone: The Case for Nginx in Scalable Web Services

Why Nginx Is Required When Using Only Tomcat

When a browser sends an HTTP request it first resolves the domain via DNS to an IP address; the IP must belong to a public server running Tomcat. Using only Tomcat quickly runs into several practical issues.

DNS can bind at most three IP addresses, so expanding beyond three Tomcat instances is impossible.

Ten services would require ten separate Tomcat clusters, meaning 30 public‑IP servers and high cost.

Each service needs its own domain, leading to a proliferation of domain registrations.

Purchasing and managing dozens of public IPs is expensive.

Public servers must be protected by firewalls and other security measures, increasing operational overhead.

Tomcat cannot serve static files efficiently in a front‑end/back‑end separated architecture; a dedicated web server like Nginx or Apache is needed.

During a Tomcat deployment the server is temporarily unavailable; any request hitting the publishing node fails. Because DNS points to three servers, the failure rate can be as high as one‑third, which is unacceptable in production.

Why DNS Can’t Automatically Remove Faulty IPs

DNS only resolves domain names to IP addresses; it does not monitor server health or Tomcat status, so it cannot automatically drop a failing IP.

Can I Manually Remove a Faulty IP?

Yes, but the change is subject to the DNS TTL (default 10 minutes). Even after removing an IP, clients continue to use the old address until the cache expires, causing additional request failures.

What Happens When a Node Crashes?

Manual removal is too slow for sudden crashes. An automated health‑check and retry mechanism is needed, which is exactly what Nginx provides.

Nginx Health Check and Failover

Nginx can detect failed upstream Tomcat nodes and automatically retry requests on a healthy node. Example upstream configuration:

<code>upstream test {
    server 127.0.0.1:8001 fail_timeout=60s max_fails=2;  # Server A
    server 127.0.0.1:8002 fail_timeout=60s max_fails=2;  # Server B
}
</code>

If Server A returns a connection error, Nginx forwards the request to Server B. After two consecutive failures, Server A is removed from the active list for 60 seconds, after which Nginx retries it again. The client never sees the failure because Nginx transparently retries.

Nginx Virtual Hosts and Reverse Proxy

Multiple sub‑domains can be mapped to different directories or Tomcat clusters. Example of static‑file virtual hosts:

<code>http {
    include mime.types;
    default_type application/octet-stream;
    sendfile on;
    keepalive_timeout 65;
    server {
        listen 80;
        server_name www.abc.com;
        location / {
            root html/www;
            index index.html index.htm;
        }
    }
    server {
        listen 80;
        server_name bbs.abc.com;
        location / {
            root html/bbs;
            index index.html index.htm;
        }
    }
    server {
        listen 80;
        server_name blog.abc.com;
        location / {
            root html/blog;
            index index.html index.htm;
        }
    }
}
</code>

And reverse‑proxying different paths to distinct Tomcat clusters:

<code>upstream serverGroup1 {
    server 192.168.225.100:8080;
    server 192.168.225.101:8082 weight=2;
    server 192.168.225.102:8083;
    server 192.168.225.103:8084 backup;
}
upstream serverGroup2 {
    server 192.168.225.110:8080;
    server 192.168.225.111:8080 weight=2;
    server 192.168.225.112:8080;
    server 192.168.225.113:8080 backup;
}
server {
    listen 80;
    server_name picture.itdragon.com;
    location /group1 {
        root html;
        proxy_pass http://serverGroup1;
        index index.html index.htm;
        deny 127.0.0.1;
        allow 192.168.225.133;
    }
    location /group2 {
        root html;
        proxy_pass http://serverGroup2;
        index index.html index.htm;
        deny 127.0.0.1;
        allow 192.168.225.133;
    }
    error_page 500 502 503 504 /50x.html;
    location = /50x.html {
        root html;
    }
}
</code>

Conclusion

Using only Tomcat is impractical for production due to DNS limits, cost, lack of health checks, and inability to serve static assets. Nginx complements Tomcat by providing load balancing, automatic failover, health monitoring, and virtual‑host capabilities, making the overall architecture reliable and scalable.