Overview
This endpoint showcases KrakenD’s rate limiting capabilities at both the endpoint (router) and backend (proxy) levels while aggregating data from multiple sources. HTTP Method:GETEndpoint:
/shop
What It Demonstrates
- Multi-level Rate Limiting: Implements rate limits at both router and proxy levels
- Data Aggregation: Combines campaigns and products data
- Backend Rate Limiting: Protects individual backend services from overload
- Endpoint Rate Limiting: Controls overall request rate to the endpoint
Request Example
Expected Response
Rate Limiting Behavior
When rate limits are exceeded, KrakenD returns: Status Code:429 Too Many Requests
Backend Services Called
1. Campaigns Service
- Host:
http://fake_api(inherited from global config) - URL Pattern:
/shop/campaigns.json - Allowed Fields:
campaigns - Rate Limit: None (uses endpoint-level limit)
2. Products Service
- Host:
http://fake_api(inherited from global config) - URL Pattern:
/shop/products.json - Allowed Fields:
products - Backend Rate Limit: 1 request per second, capacity of 1
KrakenD Configuration
Key Configuration Options
Endpoint-Level Rate Limiting (qos/ratelimit/router)
- Purpose: Limits requests to the entire
/shopendpoint - Max Rate: 2 requests per second
- Scope: Applied before backend calls are made
- Use Case: Protects your infrastructure from overall load
Backend-Level Rate Limiting (qos/ratelimit/proxy)
- Purpose: Limits requests to the products backend service
- Max Rate: 1 request per second
- Capacity: 1 (token bucket capacity)
- Scope: Applied only to the products backend
- Use Case: Protects specific backend services with strict rate limits
Rate Limit Tiers
With this configuration:- Overall endpoint limit: 2 req/sec (router level)
- Products backend limit: 1 req/sec (proxy level)
- Campaigns backend: No specific limit (controlled by endpoint limit)
Token Bucket Algorithm
KrakenD uses the token bucket algorithm for rate limiting:- max_rate: Tokens added per second
- capacity: Maximum tokens that can accumulate
- Behavior: Allows bursts up to capacity, then enforces steady rate
Use Cases
- E-commerce API gateways
- Protecting legacy backend systems
- Implementing tiered rate limits
- Preventing backend overload
- Cost control for pay-per-request APIs
- Quality of Service (QoS) enforcement
Testing Rate Limits
Test the rate limiting behavior:- First 2 requests succeed (200 OK)
- Subsequent requests return 429 (Too Many Requests)
- After waiting 1 second, requests succeed again