Skip to content

Rate Limits

Rate Limits

Rate limiting helps protect your application from abuse by controlling the number of requests a client can make within a specified time period. Arxignis supports both fixed window and leaky bucket rate limiting algorithms.

Configuration Structure

rate_limit:
  - name: "auth_login"
    rule: (http.request.uri.path contains "/auth/login")
    type: fixed_window
    enabled: true
    limit: 100
    period: 60
    burst: 100
  - name: "auth_register"
    rule: (http.request.uri.path contains "/auth/register")
    type: leaky_bucket
    enabled: true
    limit: 100
    period: 60
    burst: 100

Configuration Options

Name

  • Type: String
  • Required: Yes
  • Description: Unique identifier for the rate limit rule
  • Example: name: "auth_login"

Rule

  • Type: String
  • Required: Yes
  • Description: Wirefilter expression to match requests
  • Example: rule: (http.request.uri.path contains "/auth/login")

Type

  • Type: String
  • Required: Yes
  • Options: fixed_window, leaky_bucket
  • Description: Rate limiting algorithm to use
  • fixed_window: Simple counting of requests in a time window
  • leaky_bucket: Smooths out request processing
  • Example: type: "fixed_window"

Limit

  • Type: Integer
  • Required: Yes
  • Description: Maximum number of requests allowed in the period
  • Example: limit: 100

Period

  • Type: Integer
  • Required: Yes
  • Description: Time period in seconds
  • Example: period: 60

Burst

  • Type: Integer
  • Required: Yes
  • Description: Maximum number of requests allowed in burst
  • Example: burst: 100

Enabled

  • Type: Boolean
  • Default: true
  • Description: Whether the rule is active
  • Example: enabled: true

Rate Limiting Algorithms

Fixed Window

  • Simple counting of requests in a time window
  • Resets at the end of each period
  • Can allow bursts at window boundaries
  • Good for simple use cases

Leaky Bucket

  • Smooths out request processing
  • Maintains a constant rate
  • Better for handling bursts
  • More complex but more predictable

Best Practices

  1. Use appropriate rate limits based on your application's needs
  2. Consider using different algorithms for different endpoints
  3. Set reasonable burst limits
  4. Monitor rate limit effectiveness
  5. Use descriptive names for rules

Example Configurations

API Rate Limiting

rate_limit:
  - name: "api-general"
    rule: (http.request.uri.path starts_with "/api/")
    type: leaky_bucket
    limit: 1000
    period: 60
    burst: 100
    enabled: true

Authentication Endpoints

rate_limit:
  - name: "login-attempts"
    rule: (http.request.uri.path contains "/auth/login")
    type: fixed_window
    limit: 5
    period: 300
    burst: 5
    enabled: true

Common Use Cases

  1. API Protection: Limit API requests to prevent abuse
  2. Login Protection: Restrict login attempts to prevent brute force
  3. Resource Protection: Limit access to resource-intensive endpoints
  4. Public Endpoints: Higher limits for public-facing endpoints