How to Implement Rate Limiting in Your SaaS Without Killing User Experience
Every SaaS hits the same wall: one customer runs a script that consumes 40% of your API budget, or your public endpoint gets scraped by a competitor. Rate limiting fixes this, but naive implementation destroys user trust. Here’s how to do it right.
Quick Answer
Implement rate limiting at three layers: per-user limits for authenticated requests, per-IP limits for public endpoints, and per-endpoint limits for expensive operations. Use a sliding window algorithm for accuracy, and always return meaningful 429 responses that tell users when they can retry.
Why Rate Limiting Matters in 2026
AI agents are changing traffic patterns. A single user running an AI-powered automation can generate 500+ requests/minute without malicious intent — they’re just using your API efficiently. Strict rate limits tuned for 2023 traffic patterns now break legitimate use cases. Your rate limiting strategy needs to distinguish between bot abuse and efficient AI usage.
Common Mistakes
Using Fixed Windows Instead of Sliding Windows
Fixed window rate limiting (e.g., “100 requests per hour”) creates edge cases where users get 2x throughput by timing requests around the window boundary. Sliding window algorithms provide even distribution and prevent abuse at boundaries.
Returning Cryptic Error Codes
A 429 status with no body tells users nothing. Always include headers and response body with: current limit, remaining requests, reset time, and retry-after if applicable.
Not Prioritizing Authenticated Users
Public endpoints attract both legitimate users and scrapers. Your rate limit for unauthenticated requests should be 10x lower than for authenticated users, but never zero — you want new users to be able to explore.
Decision Framework
| Endpoint Type | Limit | Window | Algorithm |
|---|---|---|---|
| Read API (authenticated) | 1000 | 60 seconds | Sliding window |
| Write API (authenticated) | 100 | 60 seconds | Sliding window |
| Public endpoints | 30 | 60 seconds | Token bucket |
| AI/complex endpoints | 10 | 60 seconds | Leaky bucket |
Recommended Implementation
Using Upstash Redis
Upstash provides serverless-friendly Redis with per-request pricing that matches SaaS billing models. Their rate limiting SDK handles sliding window logic:
import { Ratelimit } from "@upstash/ratelimit";
import { Redis } from "@upstash/redis";
const ratelimit = new Ratelimit({
redis: Redis.fromEnv(),
limiter: Ratelimit.slidingWindow(100, "60 s"),
analytics: true,
});
const { success, limit, remaining, reset } = await ratelimit.limit("user-123");
if (!success) {
return res.status(429).json({
error: "Rate limit exceeded",
limit,
reset: new Date(reset).toISOString(),
retryAfter: Math.ceil((reset - Date.now()) / 1000)
});
}Using Cloudflare Workers
Cloudflare’s built-in rate limiting requires no external service:
addEventListener("fetch", event => {
const data = request.limit(10, { key: request.headers.get("CF-Connecting-IP") });
if (!data.success) {
return new Response("Rate limit exceeded", {
status: 429,
headers: { "Retry-After": data.headers.get("Retry-After") }
});
}
});Handling Edge Cases
AI agents sending batch requests: Consider implementing batch endpoints that accept multiple operations in one request. This lets AI users be efficient while you track aggregate usage.
Enterprise customers with legitimate high-volume needs: Offer tiered rate limits based on plan. Enterprise can get 10x consumer limits with dedicated infrastructure.
Internal tools hitting your public API: Use separate API keys for internal services with higher limits. Never let internal traffic compete with customer traffic.
The Bottom Line
Good rate limiting is invisible to legitimate users and painful only to abusers. Implement sliding windows, return helpful 429 responses, and tune limits based on actual traffic analysis. Review your limits quarterly as user patterns change with AI adoption.
Limitations
- Redis dependency: Rate limiting adds Redis as a critical dependency. Redis outage means no rate limiting (default to open or closed).
- Geographic latency: Distributed rate limiting requires either regional Redis instances or accepting ~10ms added latency.
Advanced Rate Limiting Patterns
Burst handling is a common challenge. Token bucket algorithms allow brief bursts above your rate limit while maintaining long-term averages. Implement this for APIs where brief traffic spikes are normal.
Concurrent request limiting complements per-time-window limits. Some attacks use many slow connections rather than many requests. Track concurrent authenticated sessions and limit simultaneous connections per user.
Enterprise Considerations
Large-scale rate limiting requires distributed state. Redis Cluster or DynamoDB handles this at scale, but adds latency.
FAQ
Should I rate limit by IP or by user?
Both. Use IP for unauthenticated requests, user ID for authenticated requests. VPN users behind the same IP should each get their own quota.
How do I determine the right limits?
Start with generous limits, then analyze actual traffic. Look at the 95th percentile of requests per user, not the average.
What should a 429 response include?
Minimum: current limit, remaining requests, reset time. Optional but helpful: retry-after in seconds, link to documentation explaining the limit.
Can I implement rate limiting without Redis?
Yes, but with trade-offs. In-memory tracking works for single-instance deployments but fails horizontally. Use a distributed store for production.
How do I handle rate limiting for WebSocket connections?
WebSocket rate limiting is connection-based, not request-based. Limit concurrent connections per user and messages per connection per minute.
Should I notify users before they hit limits?
Yes. Show users their current usage in dashboards and send warnings at 80% of their limit. Prevention beats frustration.