Building a High‑Performance Access Gateway with OpenResty: Design & Implementation

Preface

Previously I shared some gateway‑related articles and noticed strong interest, so today we discuss how to build a gateway system with OpenResty. Our own access‑layer gateway uses OpenResty, and this article summarizes its design and key OpenResty concepts to give a comprehensive understanding of this high‑performance web platform.

Gateway Role

The gateway is the entry point for all traffic, handling security, rate limiting, circuit breaking, monitoring, logging, risk control, authentication, etc. There are two types of gateways:

Access gateway: responsible for routing, WAF (preventing SQL injection, XSS, path traversal, data theft, CC attacks), rate limiting, logging, caching, and forwarding requests to application‑layer gateways.

Application gateway: used in micro‑service architectures to route requests to language‑specific service clusters, perform authentication, timeout, retry, and circuit‑break functions.

Because the access gateway carries all company traffic, its performance is critical, and its design determines the system’s ceiling.

Access‑Layer Gateway Architecture & Implementation

The core function is "distribute requests to the appropriate backend cluster according to routing rules" . Required functional models include:

Routing: forward requests to upstream clusters based on host, URL, etc.

Plugin‑based routing strategy: authentication, rate limiting, security rules, etc., are implemented as independent, dynamically configurable plugins that can be added or removed without restarting the service.

Dynamic backend cluster changes: support adding or removing backend instances on the fly.

Monitoring and statistics: request volume, error rate, logging, alerting, and analysis.

Technology Selection

Although Nginx can handle high concurrency, it requires configuration reloads for any change, lacking a runtime API. OpenResty (Nginx + Lua) provides dynamic, scriptable behavior without restarts, making it ideal for an access gateway.

OpenResty® is a high‑performance web platform based on Nginx and Lua, integrating many Lua libraries and third‑party modules. It enables building highly concurrent, highly extensible dynamic web applications, services, and gateways.

OpenResty combines Nginx’s event‑driven, non‑blocking I/O with Lua’s scripting, allowing runtime control of routing, upstreams, SSL, requests, and responses without restarting.

Key advantages:

Comprehensive documentation and test cases

Synchronous non‑blocking model – Lua coroutines provide cooperative multitasking, enabling high concurrency.

Example of synchronous vs. blocking:

local res, err = query-mysql(sql)
local value, err = query-redis(key)

Synchronous : the Redis query must wait for the MySQL query to finish.

Blocking : if the CPU does nothing else during the I/O wait, it is blocking; otherwise it is non‑blocking.

OpenResty Internals

Working Principle

OpenResty inherits Nginx’s architecture: a master process manages multiple worker processes. Workers handle client requests using an event‑driven, epoll‑based model, allowing many concurrent connections with a single thread per worker.

Each worker runs a LuaJIT VM; Lua coroutines cooperate with Nginx’s event loop. When a coroutine performs I/O (e.g., MySQL or network), it yields, Nginx registers a callback, and the worker can process other requests. Once the I/O completes, Nginx resumes the coroutine, achieving synchronous non‑blocking behavior.

OpenResty Request Lifecycle

Nginx processes a request in 11 phases, each with a corresponding *_by_lua directive:

set_by_lua: set variables;
rewrite_by_lua: rewrite/redirect;
access_by_lua: authentication/authorization;
content_by_lua: generate response body;
header_filter_by_lua: filter response headers;
body_filter_by_lua: filter response body;
log_by_lua: log request.

This separation allows adding encryption in the access phase and decryption in the body‑filter phase without touching core business logic.

Shared Dictionary (shared dict)

Workers are independent processes; OpenResty provides a high‑performance shared memory dictionary (shared dict) with atomic Lua APIs for cross‑worker data sharing, avoiding contention under high concurrency.

Plugin‑Based Routing Strategy

Routing policies consist of URL, action, and target cluster, stored in a database and compiled into Lua functions at init time. Workers fetch rules once, cache them in shared dict, and apply them per request. Changes are propagated via a management API that triggers a reload.

Dynamic Backend Cluster Configuration

Static upstream definitions in Nginx require manual reloads. OpenResty’s dyups module provides an API to add, delete, or modify upstreams at runtime, eliminating the need for reloads.

-- Dynamic upstream API server
server {
    listen 127.0.0.1:81;
    location / {
        dyups_interface;
    }
}

-- Add upstream:user_backend
curl -d "server 10.53.10.191;" 127.0.0.1:81/upstream/user_backend

-- Delete upstream:user_backend
curl -i -X DELETE 127.0.0.1:81/upstream/user_backend

Using dyups solves dynamic upstream management.

Final Gateway Architecture Diagram

The design achieves a configurable, dynamic gateway.

Conclusion

The gateway, as the entry point for all traffic, demands high performance; therefore, careful technology selection is essential. OpenResty offers high performance, proven adoption by major companies, and rich features such as plugin‑based routing, dynamic upstreams, and shared data structures, making it a solid choice for building robust access gateways.