Rate Limiting System Development for Crypto Exchange API

Note: when an API key sends 10,000 requests per second to the /order endpoint without a rate limiting system, the backend goes down in a minute. We design and implement protection that cuts off anomalous traffic while keeping the system responsive for legitimate users. Unlike off-the-shelf gateways, our solution accounts for the specifics of crypto exchanges: different limits for maker/taker, WebSocket connections, and bursts based on balance. On a real project with a peak load of 50k RPS, we reduced the number of rejected legitimate requests by 3x compared to the standard Nginx limit_req. The foundation is a combination of token bucket and sliding window log on Redis Cluster. The former allows short-term bursts, the latter provides accurate accounting within a sliding window.

Why rate limiting is critical for a crypto exchange?

The crypto exchange API is a prime target for bots and scripts. Without rate limiting, an attacker can:

• Launch a DDoS using a single key, utilizing all 10 Gbps of the channel
• Scrape all orders in seconds (data scraping) – up to 100,000 requests per minute
• Take down the /order endpoint with excessive requests, causing timeouts for legitimate traders

We've encountered cases where high-frequency traders accidentally sent 5000 requests per second to /balance, crashing the matching engine. Our system cuts off such anomalies without human intervention, with a latency of no more than 2 ms.

Which algorithm to choose for reliable rate limiting?

Token bucket provides flexibility: you set the refill rate (e.g., 100 tokens/s) and bucket size (burst up to 500 tokens) – bursts up to 5x the average limit pass without blocking. Sliding window log is more precise: it counts requests in a moving window and does not allow exceeding the limit even for a second. We combine both: token bucket for most endpoints, sliding window for critical ones (e.g., /withdraw). This gives the best protection and minimal false positives – 3x fewer than the standard limit_req.

What is included in the rate limiting work?

We deliver a complete set of deliverables:

• Architecture and rules documentation
• Access to Grafana dashboards (logs, metrics, alerts)
• Operations team training (2-3 sessions)
• Support during the deployment phase for 2 weeks

How we design the rate limiting system

Architecture and stack

Nginx configuration example

http { limit_req_zone $binary_remote_addr zone=api:10m rate=100r/s; server { location /api/v1/ticker { limit_req zone=api burst=50 nodelay; proxy_pass http://backend:8080; } } } 

Lua script for Redis (token bucket)

local key = KEYS[1] local rate = tonumber(ARGV[1]) local capacity = tonumber(ARGV[2]) local now = redis.call('TIME')[1] local bucket = redis.call('HGETALL', key) local tokens = bucket[1] and tonumber(bucket[1]) or capacity local lastRefill = bucket[2] and tonumber(bucket[2]) or now local tokensToAdd = (now - lastRefill) * rate / 1000 if tokensToAdd > 0 then tokens = math.min(capacity, tokens + tokensToAdd) lastRefill = now end if tokens >= 1 then tokens = tokens - 1 redis.call('HMSET', key, tokens, lastRefill) redis.call('EXPIRE', key, 10) return 1 else return 0 end 

The implementation is based on the official example from Redis documentation — Token Bucket Lua script. For WebSocket connections, we configure a separate token bucket with a key by user_id and a limit of 10 messages per second. We use Redis Pub/Sub for synchronization between nodes.

Advantages of custom solution over ready-made gateways

Ready-made gateways like Kong or AWS API Gateway do not support custom limits for WebSocket, distinction of rights for maker/taker, or burst mechanism based on balance. Our solution is tailored for the exchange: you set the user tier (VIP gets 1000 r/s, regular 10), configure logic for each endpoint, and integrate with your billing or scoring system.

Step-by-step implementation: from analysis to monitoring

1. Load profile analysis. Collect logs for a month, determine request distribution across endpoints, peak hours, typical anomalies.
2. Rule design. Develop tier grid, limits for each route, exceptions for WebSocket.
3. Middleware implementation. Write in Go or Lua in Nginx – add a handler that checks the limit before passing the request to the backend.
4. Redis integration. Set up cluster, key TTL, pipelines to reduce latency.
5. Load testing. Run wrk and k6 up to 100k RPS, ensure the rate limiter does not become a bottleneck.
6. Dashboards and alerts. In Grafana visualize: number of rejected requests, violating keys, Redis resource usage. Set up alerts for threshold breaches.
7. Documentation and training. Hand over operations manual: how to add rules, manually disable blocks, analyze logs.

Estimated timelines

Full turnkey implementation: from 5 to 8 weeks depending on API complexity.

How do we guarantee stability?

We have been developing crypto exchange backends for over 5 years. During this time, we have implemented rate limiting systems for projects with a daily audience of >1 million users and peak load >50k RPS. We guarantee that your system will pass security audit and withstand any loads within the agreed capacity. Average infrastructure cost savings due to optimization reach 30%.

Contact us for a free consultation – we will assess your architecture and propose an optimal rate limiting scheme. Request an audit of your current system and receive a 10% discount.