Configuration ‐ Service Module ‐ Rate Limiter

When the Service Module is enabled, rate limiting is applied to the calculation endpoints. The rate limiter is preconfigured with default settings, but you can adjust these to fit your specific requirements.

🛠️ Configuration

The rate limiter is configured via the RateLimiter.json file.

Default configuration:

{
  "RateLimiter": {
    "Anonymous" : "SlidingWindow::10/60-10"
  }
}

You can modify the Rate Limiter using Production Overrides by creating a RateLimiter.Production.json file, or by using Environment Variables.

• 📁 Location: /app/Config_Files/ServiceModule
• 📌 Full Path: /app/Config_Files/ServiceModule/RateLimiter.Production.json

For more information on this refer to the Configuration page.

🔧 Configuration Options

• Anonymous: Specifies the rate limiter settings for anonymous users. This global setting applies to all anonymous users collectively, meaning the limit is shared across all users. For example, if you set the rate limit to 10 requests per minute, it applies to all anonymous users combined, not individually.

⚙️ Rate Limiter Configuration

The rate limiter configuration follows the format:

{RateLimiterType}::{RateLimiterConfiguration}

🔑 Supported Rate Limiter Types

• Fixed Window (FixedWindow)
• Sliding Window (SlidingWindow)

🕰️ Fixed Window

The Fixed Window rate limiter enforces a hard limit on the number of requests within a fixed time window. It applies a constant rate limit regardless of when the requests occur within the window.

Configuration Format:

{Number of requests}/{Time in seconds}

Example:

FixedWindow::10/60

• FixedWindow: Uses the fixed window strategy.
• 10: Allows 10 requests during the time window.
• 60: Time window lasts 60 seconds (1 minute).

This configuration limits users to a maximum of 10 requests every 60 seconds, with the counter resetting at the end of each window.

↔️ Sliding Window

The Sliding Window rate limiter provides a more adaptive approach by dividing the time window into smaller segments. This smoother traffic handling reduces sudden bursts or idle periods, ensuring a more consistent request flow.

Configuration Format:

{Number of requests}/{Time in seconds}-{Number of segments}

Example:

SlidingWindow::100/30-3

• SlidingWindow: Uses the sliding window strategy.
• 100: Allows 100 requests during the full time window.
• 30: Time window lasts 30 seconds.
• 3: The window is divided into 3 segments.

In this configuration, the time window is split into 3 segments. When requests in expired segments are processed, they’re recycled into the current segment, leading to a more balanced distribution of requests over time.