How to Strategically Apply Rate Limiting Across SLB, Nginx, and Spring Cloud Gateway

The guiding principle of rate limiting is to restrict traffic as close to the source as possible, using the skills and tools available to the team.

SLB Node

All external traffic—business, non‑business, DDoS, normal requests, crawlers—passes through the SLB entry point, so it should be the first place to intercept unwanted flows.

Intercepted traffic: DDoS attacks, generic unsafe traffic such as SQL injection and XSS.

Rate‑limiting measures: connection concurrency limits, per‑IP request limits, crawler throttling.

Because SLB configuration is UI‑based and not easily version‑controlled, many teams move these rules to downstream Nginx/Kong where they can be stored as code and restored quickly with scripts.

Nginx/Kong Node

After SLB, most malicious traffic (DDoS, common injections) is already filtered, but crawlers and some advanced attacks may remain.

Rate‑limiting actions: throttle crawlers, control concurrency, filter or redirect to a honeypot system, per‑IP request limits.

Spring Cloud Gateway Node

This layer handles dynamic Java traffic, which has a lower capacity than Nginx, requiring more granular controls.

Normal rate limiting.

Burst traffic control (e.g., flash‑sale spikes).

CC attack and signature verification filtering.

Dynamic routing can configure individual rate‑limit rules and custom CC+signature checks.

Isolation is crucial because the gateway forwards requests to many microservices; a single slow service should not affect others.

Techniques: circuit breakers such as Hystrix, Sentinel, or Guava.

Differences Between Nginx and Gateway Rate Limiting

Nginx thresholds are higher because it serves a broader range of traffic, including static H5 resources.

Gateway rate limiting is more flexible, allowing custom KeyResolvers for dimensions like user ID, IP, tenant, etc.

Java Microservice Node

Each microservice’s capacity can be measured (e.g., with JMeter) and used to set appropriate limits.

Additional dimensions: per‑service limits, queue‑based throttling, dedicated thread pools for inbound and outbound calls to avoid cross‑service impact.

Circuit breaking ensures that slow downstream services do not drag down the caller.

Overall, combining proper rate limiting, isolation, and circuit‑breaker strategies across these layers helps maintain stability and security in cloud‑native architectures.