Why Rate Limit

Protect against abuse.

Prevent single user from degrading service.

Control costs (AI APIs).

Enforce plan limits.

DoS protection.

Where to Apply

API gateway level.

Application level.

Database level.

Different granularity for different needs.

Common Algorithms

Fixed window: 100 requests per hour.

Sliding window: rolling 60 minutes.

Token bucket: tokens refill over time.

Leaky bucket: constant rate output.

Fixed Window

Simple: counter per period.

Problem: bursts at window boundaries.

OK for: simple rate limits, non-critical.

Reset time: minute/hour boundary.

Sliding Window

More accurate.

Complex to implement.

Counts requests in last N minutes.

Good balance most cases.

Token Bucket

Allows bursts.

Tokens refill at set rate.

Bucket has max capacity.

Good for: APIs where burst is normal.

Leaky Bucket

Enforces steady rate.

Excess requests dropped or delayed.

Good for: preventing overload.

Bad for: latency-sensitive.

Storage Backend

Redis: fast, distributed.

In-memory: fastest but not distributed.

Database: slower, generally avoid.

Choose based on scale.

Per-User vs Global

Per-user: fair, prevents individual abuse.

Global: protects total resources.

Usually combine both.

IP-based: fallback for anonymous.

Response Codes

429 Too Many Requests.

Retry-After header: when to retry.

X-RateLimit headers: current status.

Clear error message.

Graceful Degradation

Not just deny requests.

Prioritize critical operations.

Queue non-critical for later.

Serve cached responses if possible.

Plan-Based Limits

Free: 100/hour.

Paid: 1000/hour.

Enterprise: custom.

Different limits per endpoint tier.

Bypass for Internal

Internal services shouldn’t be rate limited.

API keys or IPs bypass.

Testing accounts.

Documentation clear.

Monitoring

Rate limit hits: which users?

By endpoint.

Legitimate users hitting limits: raise them.

Suspicious patterns: block.

Distributed Rate Limiting

Multiple servers.

Redis for shared state.

Latency of Redis lookup.

Approximate counters for scale.

Common Mistakes

Rate limiting only on obvious endpoints.

No user feedback (silent 429).

Same limit for all users.

Not monitoring effectiveness.

Hardcoded limits (no config).

Tools

nginx: basic rate limiting built in.

Redis: token bucket implementation.

Cloudflare: edge rate limiting.

AWS API Gateway: managed rate limits.

Our Implementation

API gateway: coarse limits.

Application: fine-grained, per-user.

Business logic: plan-based limits.

Redis for state.

Monitored via metrics.

Based on Real Projects

This guide is based on our work with:

• Platforma365
• Nasca

Further Reading

If this guide helped you, you might also want to read our comprehensive guide on Custom SaaS Development.