How MOAT Enables Lightweight, Multi‑Dimensional Rate Limiting for Scalable Systems

1. Introduction

As the number of WOS users grows, system stability becomes critical; traffic spikes require effective rate limiting, and malicious traffic such as fraudulent orders also needs business‑level throttling.

2. Background

Rate‑limiting requirements include business‑dimension limits (e.g., API call quotas), system stability protection, and abnormal traffic handling with automatic blacklisting.

3. Goals

MOAT aims to provide lightweight, extensible, multi‑dimensional rate limiting with a closed‑loop process: configure rule strategy, detect risk, add to blacklist, limit request, release blacklist.

Business configures rule strategy.

Rules drive request interception.

On interception, perform post‑processing such as adding to blacklist.

Subsequent matching requests are blocked for the blacklist duration.

Release the block to resume traffic.

Implemented features are shown below.

4. Technical Solution

4.1 Overall Architecture

The system is divided into four layers:

Access layer: supports automatic HTTP and Dubbo filters and programmatic API access.

Logic layer: implements interception checks, rate calculations, trigger handling, and release.

Data layer: stores intermediate calculation data and interception results; uses Redis in cluster mode or local memory in single‑node mode.

Log layer: records results via CAT for analysis.

4.2 Client

The client interaction consists of three phases: startup (fetch and load rules), business call (apply rules), and rule update (hot‑reload when rules change).

Application startup: the client contacts the MOAT management server to pull rules every second.

Business call: the SDK processes the request according to loaded rules.

Rule change: the client updates rules in real time after publishing.

4.3 Detailed SDK Interception Flow

Parse request and determine if the resource is managed.

Parse model to build rule instance data.

Validate request against blacklist and thresholds.

Accumulate request counts using fixed or sliding windows.

Log processed and blocked requests to CAT.

4.4 Rule Update Synchronization

When an administrator publishes a rule, the client receives an update and applies the new configuration.

4.5 Invocation Methods

Besides automatic filter interception, MOAT provides a programmatic API. Example:

try {
  // resource name can be any business‑meaningful string
  EntriesDTO entriesDTO = EntriesDTO.builder()
      .resourceName("customResource")
      .args(new Object[]{avg})
      .build();
  Moat.entryWithException(entriesDTO);
  // protected business logic
} catch (MoatBlockException e) {
  // handle blocked resource
} finally {
  // cleanup code
}

5. Practice

In transaction services, MOAT effectively throttles high‑frequency operations such as flash sales, reducing invalid requests. Daily processed volume reaches millions with an interception rate around 0.23%.

6. Future Plans

Further lightweighting: reduce dependencies and support standalone mode.

Enhance algorithms: make rate‑limiting algorithms configurable.

Strengthen observability: support multiple data reporting methods.

Open‑source the project to build an ecosystem.

The article introduced MOAT’s business scenarios, design, implementation details, and practical results, inviting interested readers to contribute.