Speeding Up the Backend: How tipi.work Solved a 1.2TB Upgrade Crisis

Modern infrastructure depends on more than just powerful hardware. It requires intelligent deployment of load balancing and caching tools to ensure sites are fast, reliable, and minimize operational headaches.

At tipi.work, we specialize in designing and implementing high-performance distributed systems. Today, we want to share a compelling case where our expertise turned a system-crippling upgrade into a smooth, non-event.

The Challenge: A Performance Catastrophe

We were called in to address a critical performance issue during an application upgrade for a customer.

The Scenario: the customer runs a Tomcat-based Java Web client-server application. A new server version required hundreds of client agents to download a mandatory update to maintain compatibility. This mass download event—hundreds of simultaneous requests—caused the public-facing Web interface to become inaccessible for hours, even though the server application itself was technically operating.

Our Analysis shows the numbers quickly revealed the bottleneck:

• 1 Tomcat Application Server
• 1 thousands of clients requiring the update
• new client software size: 1.2 GB
• total data to be served simultaneously: ~1.2 TB

Crucially, this data was static content (a set of files on the file system) and not dynamic content that Tomcat needed to generate.

The Legacy File-Serving Flow:

• An agent connects to Tomcat
• Tomcat verifies the agent's version and directs it to the update
• Tomcat opens the file from the disk
• Tomcat reads the file and begins sending the 1.2 GB payload to the agent

This process tied up Tomcat’s resources, rendering it incapable of serving the dynamic web interface, leading to the system-wide outage.

The tipi.work solution: leveraging in-Memory speed

The core question was clear: how do we offload the static content delivery to free up Tomcat?

Our initial thought was to use static file serving outside of Tomcat, with an nginx filesystem-based cache. However, after measuring the I/O operations on a Linux VM, we decided to pursue a faster, less disk-reliant approach.

The fastest storage available to us was the RAM. We confirmed that the VM had sufficient available memory to host a set of files of an update, and decided to use a memory-based caching solution.

While nginx integrates well with memcached, we chose to move forward with redis due to its built-in replication and the ability to create a data dump on a disk for persistence.

The tipi.work stack for the fix:

• nginx, as the high-performance front-end proxy
• redis, as the ultra-fast in-memory static content store
• ngx_http_redis module, to seamlessly connect nginx to redis

The Implementation:

• We set up a redis NoSQL database
• We built and configured nginx with the necessary ngx_http_redis module, placing it in front of the Tomcat server
• The static update content was pushed from the filesystem into the redis database
• We configured nginx to intercept the specific "give-me-an-update" requests; nginx now uses the ngx_http_redis module to pull the file directly from RAM (via redis) and serve it back to the agents without involving Tomcat at all

Conclusion: Tremendous Performance Shift

The solution was thoroughly tested and demonstrated a tremendous performance shift upon deployment: previously, the Web UI was essentially unavailable for the hours required to complete the agent upgrade process. With the tipi.work solution deployed, the agents' update process no longer affects the Web UI availability.

By intelligently offloading the 1.2 TB of static content from the Java application server and serving it from high-speed RAM via nginx, we restored full web service availability and ensured a fast, reliable, and non-disruptive upgrade experience for the client.