Backend Development 5 min read

OpenResty‑Based Architecture: Nginx, Lua, Redis Caching, Compression, and Scheduled Updates

This article explains how to use OpenResty with Lua to integrate Nginx and Redis for high‑performance caching, data compression, timed updates, and configurable URL management, enabling resilient backend services that continue serving content even when application servers fail.

Architect
Architect
Architect
OpenResty‑Based Architecture: Nginx, Lua, Redis Caching, Compression, and Scheduled Updates

OpenResty is a high‑performance web platform built on Nginx and Lua, bundling numerous Lua libraries and third‑party modules to simplify the creation of scalable dynamic web applications and gateways.

By leveraging the lua-resty-redis module, Nginx can directly access Redis without occupying Tomcat threads, allowing requests to be served even if Tomcat is down, thereby reducing response latency and improving system concurrency.

Data larger than 1 KB is compressed by Nginx before being stored in Redis, which speeds up Redis reads and reduces bandwidth usage; smaller payloads (<1 KB) are left uncompressed to maintain higher TPS.

Redis values are saved as JSON objects such as {length:xxx,content:yyy} , where content holds the compressed page and length records the original size so that the consumer can decide whether decompression is required. Compression is performed with the lua-zlib library.

A timed Nginx Lua timer periodically requests Tomcat pages, compresses them, and updates Redis; cache TTL can be set long (e.g., one hour) while the update interval can be short (e.g., one minute) to keep the cache fresh.

Only worker 0 runs the scheduled update task, identified via ngx.worker.id() , while all workers handle normal request forwarding: they first try to read the HTML from Redis, fall back to Tomcat if the key is missing, and then return the page to the browser.

Caching behavior is configurable through a management backend by sending URLs such as modify?url=index&&expire=3600000&&intervaltime=300000&&sign=xxxx , where sign is a signature generated with a secret key; Nginx validates the signature using the same secret key before applying the configuration.

Backend DevelopmentRedisCachingNginxLuaOpenResty
Architect
Written by

Architect

Professional architect sharing high‑quality architecture insights. Topics include high‑availability, high‑performance, high‑stability architectures, big data, machine learning, Java, system and distributed architecture, AI, and practical large‑scale architecture case studies. Open to ideas‑driven architects who enjoy sharing and learning.

0 followers
Reader feedback

How this landed with the community

login Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.