Applications

Applications are containers for rate limiting rules. Each application represents a logical grouping of rate limits for a service or product.

What is an Application?

Each application has:

• Default token bucket: A fallback rate limit with configurable refill and burst rates
• Multiple specific rules: Operation-based or path-based rules for fine-grained control
• Ownership: Assigned to a user or organization for access control

Why Applications?

Applications provide several benefits:

1. Organization

Group related rate limits together in a logical structure. Instead of having a flat list of hundreds of rate limits, organize them by service or product area.

Example:

Email Service Application
├── sendEmail rule
├── sendBulkEmail rule
└── verifyEmail rule

API Gateway Application
├── POST /api/users rule
├── GET /api/data rule
└── DELETE /api/items rule

2. Isolation

Keep rate limits separate between different services. Changes to one application don’t affect others, and you can delete an entire application’s rate limits without impacting other services.

3. Automatic Defaults

Every application has a default token bucket that automatically applies to operations or paths that don’t have specific rules. This means:

• No unprotected endpoints: Everything gets rate limited by default
• Quick setup: Create an application and start rate limiting immediately
• Add rules as needed: Start simple, add specific rules when you need fine-grained control

4. Simplified Management

Manage all rate limits for a service in one place:

• View all rules for a service at a glance
• Update default limits that apply to all unspecified operations
• Monitor usage across an entire service
• Grant or revoke access to an entire service’s rate limits

Application Structure

Default Token Bucket

Every application has a default token bucket with:

• Refill Rate: Tokens added per second (e.g., 10 tokens/second)
• Burst Rate: Maximum tokens in the bucket (e.g., 100 tokens)

This default bucket is used when no specific rule matches a request.

Specific Rules

Applications can contain any number of specific rules:

• Operation-based rules: For non-HTTP operations like "sendEmail"
• Path-based rules: For HTTP endpoints like POST /api/users

Each rule can have its own refill and burst rates, independent of the application defaults.

Example Use Cases

Multi-Service Architecture

Application: Email Service
Default: 10 tokens/sec, burst 100
Rules:
  - sendEmail: 5 tokens/sec, burst 50
  - sendBulkEmail: 1 token/sec, burst 10
  - verifyEmail: 20 tokens/sec, burst 200

Application: Payment Processing
Default: 5 tokens/sec, burst 50
Rules:
  - processPayment: 2 tokens/sec, burst 20
  - refundPayment: 1 token/sec, burst 10

Application: Public API
Default: 100 tokens/sec, burst 1000
Rules:
  - POST /api/users: 10 tokens/sec, burst 100
  - GET /api/data: 100 tokens/sec, burst 500
  - DELETE /api/items: 5 tokens/sec, burst 50

Different Environments

Create separate applications for different environments:

Application: Production API
Default: 100 tokens/sec, burst 1000

Application: Staging API
Default: 50 tokens/sec, burst 500

Application: Development API
Default: 10 tokens/sec, burst 100

Per-Customer Applications

For multi-tenant systems, create applications per customer:

Application: Customer A - API Access
Default: 100 tokens/sec, burst 1000

Application: Customer B - API Access
Default: 50 tokens/sec, burst 500

Application: Customer C - Premium - API Access
Default: 500 tokens/sec, burst 5000

Creating Applications

Applications are created through the LightRate dashboard or API with:

1. Name: A descriptive name for your application
2. Default Refill Rate: Tokens added per second for the default bucket
3. Default Burst Rate: Maximum tokens for the default bucket

Once created, you’ll receive an Application ID that you’ll use in your API calls and SDK configuration.

Best Practices

1. Meaningful Names

Use clear, descriptive names that indicate what the application is for:

• ✅ “Email Service”, “Payment API”, “Public REST API”
• ❌ “App 1”, “Test”, “Production”

2. Organize by Service Boundary

Create applications that align with your service architecture:

• One application per microservice
• One application per major feature area
• Separate applications for different environments

3. Set Conservative Defaults

Start with conservative default rate limits:

• Monitor actual usage patterns
• Increase limits as needed
• Use specific rules for endpoints that need higher limits

4. Document Your Setup

Keep track of:

• What each application is for
• Why specific limits were chosen
• Which services or teams own each application

Next Steps

• Rules - Learn how to create specific rate limiting rules within applications
• Token Bucket Algorithm - Understand how rate limiting works under the hood
• Quick Start - Create your first application