CASE STUDY

Optimizing a Mission-Critical NGINX Load Balancing Platform at Scale

Ashnik Team

  • Industry :
    Financial Services / Credit Information Services
  • Technology :
    NGINX Plus, RHEL, Keepalived
  • Engagement :
    Performance Optimization, Configuration Engineering, High Availability, Security Hardening and Application Delivery Modernization
THE CUSTOMER

A leading credit information services organization operates a large portfolio of business-critical applications serving internal teams, financial institutions and digital services.

THE SOLUTION

Ashnik re-engineered and optimized a critical enterprise load-balancing environment supporting a large application estate, combining configuration rationalization, high-concurrency tuning, application-aware routing, high-availability engineering and security hardening.

THE CHALLENGE

The configuration had evolved organically over time. A conventional migration of the existing configuration would simply have carried the accumulated complexity into the new environment.

THE RESULT

A cleaner, more resilient and more scalable NGINX Plus platform built according to enterprise application-delivery best practices.

600+

Backend server mappings, internal LB configuration

6 nodes

Target production NGINX footprint

4 nodes

DMZ load-balancing tier

Active/Passive

Availability model with Virtual IP

Customer Overview

A leading credit information services organization operates a large portfolio of business-critical applications serving internal teams, financial institutions and digital services.

NGINX formed an important part of the application delivery layer, routing traffic across a large backend ecosystem comprising hundreds of application and service endpoints.

Over several years, this environment had grown significantly. Multiple configurations, legacy routing definitions, application-specific session requirements and different internal and DMZ traffic patterns had accumulated.

The requirement was therefore much broader than refreshing the platform. The customer wanted to optimize a critical load-balancing environment for higher scale, stronger resiliency, improved security, easier operations and more predictable application performance.

The Challenge

The real challenge was to answer a different question: how do we engineer NGINX as a high-performance, resilient and standardized application delivery layer capable of supporting a large backend estate while simplifying operations and improving security?

Business-critical traffic across a complex estate

The NGINX estate was carrying business-critical application traffic across a large and complex backend environment.

Configuration had evolved organically

Several upstream definitions were no longer required.

Backends had moved or been replaced

Some backend services had moved or been replaced and different servers contained different versions of application-routing configuration.

Application-specific requirements

Applications had their own requirements around sessions, long-running requests, large request payloads, upstream connectivity and routing behavior.

A conventional migration would not solve it

Migrating the existing configuration would simply have carried the accumulated complexity into the new environment.

Accuracy across a large upstream estate

A single incorrect endpoint, timeout, session rule or backend mapping could affect a business application even when the load balancer itself remained healthy.

The Approach

01
Deep Assessment of the Existing Load Balancer
Ashnik analyzed application routes, upstream definitions, backend servers, connection behavior, session requirements, timeouts, buffers and traffic patterns. Existing configurations were compared to the actual target application environment to identify what needed to remain, what had changed and what could safely be removed.
02
Rationalizing Hundreds of Backend Mappings
Instead of copying the existing configuration directly, Ashnik created an old-versus-new upstream comparison model. Obsolete servers were removed, changed application servers were replaced with their new targets, new backend services were incorporated and existing valid mappings were preserved, then reconciled against the source environment.
03
Optimizing NGINX for High Concurrency
Worker processes were aligned automatically to the available CPU capacity and the worker connection model was increased to support significantly higher concurrent connection volumes, with multi-accept behavior, efficient socket handling and connection reuse. Upstream keepalive was introduced where appropriate rather than creating a new backend connection for every request.
04
Operating-System and Network Stack Tuning
File-descriptor capacity was increased, TCP socket queues and connection backlogs were tuned and receive and transmit buffers were optimized. Connection tracking capacity and ephemeral port availability were reviewed, and TCP keepalive, connection reuse and connection cleanup behavior were tuned for the workload so the operating system did not become the limiting factor.
05
Workload-Specific Buffer and Timeout Engineering
Ashnik analyzed request behavior, NGINX logs and application response patterns, then tuned client request buffers, header buffers, upstream connection timeouts, upstream response timeouts, request timeouts, proxy buffers, large-header handling and maximum request-body requirements.
06
Controlled Load Testing and Performance Analysis
Representative batch and application requests were generated through the NGINX layer. Request time, upstream connection time, upstream response time, request size, HTTP behavior and system resource utilization were analyzed, parameters were adjusted and retested, and OS statistics, socket behavior and NGINX health were monitored during testing.
07
Smarter Upstream Load Balancing
Backend pools were redesigned with persistent upstream connections, failure parameters so unhealthy application instances could be handled appropriately, and consistent session-based routing for applications dependent on JSESSIONID and similar application-session behavior. The result was application-aware load balancing aligned with how the backend systems actually operated, not merely request distribution.
08
Active Backend Health Management
NGINX Plus health-check capabilities were used where appropriate to determine whether application instances were capable of serving traffic. Backend failure thresholds and recovery behavior were defined so the load balancer could make better routing decisions, reducing dependence on manual intervention.
09
High-Availability Architecture
The internal load-balancing tier was designed as an active/passive NGINX Plus pair, with Keepalived providing Virtual IP management and failover. Applications communicate through a stable service address instead of depending directly on an individual NGINX instance.

OPTIMIZED ARCHITECTURE

opti image

SCALE OF THE PROJECT

This was a large application-delivery optimization exercise rather than a small reverse-proxy deployment. The production architecture covered six NGINX nodes across internal and DMZ traffic paths, and the internal load-balancing configuration handled 600+ backend server mappings covering a broad range of application services and microservice endpoints. Multiple existing configurations also had to be analyzed and reconciled before the final target configuration could be created.

AREA SCALE
Target production NGINX footprint 6 nodes
Internal HA load-balancing tier 2 nodes
DMZ load-balancing tier 4 nodes
Backend routing estate 600+ server mappings
Legacy DMZ configurations rationalized Multiple configurations across servers
Traffic patterns Internal, application, web and batch workloads
Availability model Active/Passive with Virtual IP
Optimization layers NGINX, OS, TCP/network, application routing and security

CONFIGURATION, SECURITY AND OPERATIONAL VISIBILITY

Configuration Best Practices Introduced

Global performance parameters were separated from application-specific routing, upstream definitions were organized and standardized, backend keepalive behavior was explicitly configured and session persistence was applied only where application behavior required it. Timeout and buffer configuration was aligned to workload characteristics, unused backend definitions were removed and logging was structured to provide better visibility into request and upstream behavior.

Security Hardening and VA Closure

Server-version exposure was disabled and communication was restricted to modern TLS protocols. Security-related HTTP headers were incorporated where applicable, access to hidden files and unnecessary paths was restricted and unnecessary information returned through upstream headers was suppressed. The environment was standardized on a current supported NGINX Plus and operating-system platform, and configuration-level observations identified during security and VA reviews were addressed.

Improved Application Behavior

Several applications depended on session persistence and complex backend-routing behavior. Ashnik recreated these application behaviors within the optimized NGINX architecture instead of treating every workload as stateless HTTP traffic, with consistent session routing where required, backend connection reuse, explicitly mapped application routing, standardized failure handling and support for large headers and application-specific request characteristics.

Operational Visibility

The NGINX Plus Dashboard was enabled and validated as part of the environment, giving operations teams greater visibility into NGINX activity and backend behavior. Combined with enhanced logging and system monitoring, the optimized environment provides much stronger diagnostic capability than simply determining whether the NGINX process is running.

RESULTS AND OUTCOMES

OPTIMIZATION AREA OUTCOME
High-concurrency tuning Increased connection-handling headroom
Linux and TCP tuning Better foundation for sustained enterprise traffic
Backend connection reuse More efficient NGINX-to-application communication
Upstream rationalization Cleaner and more accurate routing estate
600+ backend mappings Standardized and validated at scale
Session-aware routing Improved compatibility with stateful applications
Health management More resilient backend traffic distribution
Buffer and timeout tuning Better handling of diverse enterprise workloads
Active/passive architecture Improved availability of the internal LB tier
Configuration standardization Easier troubleshooting and change management
NGINX Plus Dashboard Improved operational visibility
Security hardening Improved security posture and VA closure
Modern supported platform Reduced legacy technology and maintenance risk

BUSINESS IMPACT

Greater scale

NGINX and the underlying Linux platform were engineered for much higher connection volumes, larger workloads and a backend estate containing hundreds of application mappings.

Greater reliability

Active/passive high availability, backend health management and improved failure handling strengthened the resilience of critical traffic paths.

Improved performance engineering

Performance no longer depends on generic default parameters. Worker capacity, TCP behavior, upstream connection reuse, request buffers and application timeouts are tuned around the actual workload.

Reduced configuration debt

Legacy and obsolete upstream definitions were removed while required application mappings were validated against the target environment, simplifying one of the most critical configurations in the application stack.

Stronger security

Security hardening and closure of configuration-related VA observations improved the security posture of the platform alongside the performance work.

Better operational control

A structured configuration model, NGINX Plus monitoring and improved logging gave the operations team better visibility and made future troubleshooting considerably easier.

Stronger foundation for growth

Most importantly, the optimization established a scalable NGINX Plus foundation capable of supporting future application growth without continuing to accumulate the configuration complexity of the previous environment.

FROM LEGACY LOAD BALANCING TO AN OPTIMIZED APPLICATION DELIVERY PLATFORM

BEFORE OPTIMIZED STATE
Organically grown configuration Standardized configuration architecture
Large number of historical upstreams Validated and rationalized backend estate
Generic runtime settings Workload-specific performance tuning
Limited connection optimization High-concurrency connection model
Repeated upstream connections Connection reuse with upstream keepalive
Application-specific complexity Session-aware application routing
Basic server availability High-availability NGINX Plus design
Limited health visibility Backend health management and NGINX Plus monitoring
Legacy security settings Hardened configuration and VA remediation
Platform-focused management Application-delivery-focused operations

Conclusion

For this leading credit information services organization, the engagement went significantly beyond upgrading NGINX. Ashnik re-engineered and optimized a critical enterprise load-balancing environment supporting a large application estate.

The work combined configuration rationalization, high-concurrency tuning, Linux and TCP optimization, upstream connection management, application-aware routing, session persistence, high-availability engineering, observability and security hardening. Hundreds of backend mappings were systematically reviewed and the final routing estate was validated against the target environment.

Rather than simply running a newer version of NGINX, the customer now has an optimized application delivery foundation engineered for scale, reliability, security and future growth.