การจำกัดและควบคุมอัตราการส่งคำขอของเอพีไอ

Rate limiting caps how many requests a client can make in a time window. It protects APIs from brute-force attacks, scraping, accidental loops, and denial-of-service.

It is a key control listed under API security best practices.

Rate limiting rejects requests over a hard cap; throttling slows them down (queuing or delaying) instead of rejecting outright. Both manage load and abuse, often used together.

Choose a key to count requests against:

• API key or user ID for authenticated traffic
• IP address for anonymous traffic
• Endpoint sensitivity (stricter limits on login)

Combining keys gives finer control and resists simple bypasses.

The simplest approach counts requests in a fixed time window, resetting the counter each period. It is easy but allows bursts at window edges (twice the limit across a boundary).

The token bucket refills tokens at a steady rate up to a capacity. Each request consumes a token; an empty bucket means the request is rejected. It allows controlled bursts while enforcing an average rate.

The sliding window tracks timestamps of recent requests and counts only those within the last N seconds. It avoids the burst problem of fixed windows at the cost of more bookkeeping.

With multiple servers, counters must be shared. A central store like Redis holds the counters so limits apply across the whole cluster, not per instance. Use atomic operations to avoid race conditions.

Tell clients about their limits with response headers so well-behaved clients can back off.

Return 429 Too Many Requests when a client exceeds the limit, ideally with a Retry-After header. This is the standard signal clients and SDKs expect.

Apply stricter limits to high-risk endpoints like login, password reset, and OTP verification. Tight limits here directly blunt brute-force and credential-stuffing attacks.

• Login: a few attempts per minute
• Password reset: a few per hour
• General reads: generous limits

Watch for bypasses: rotating IPs, missing limits on some routes, and limits that reset on server restart. Place rate limiting at the gateway or middleware layer so every route is covered consistently.

Test your understanding of rate limiting.

You learned why APIs need rate limiting, how to choose a limiting key, and the trade-offs of fixed-window, token-bucket, and sliding-window strategies. You also saw distributed limiting with Redis, the 429 response, and stricter limits for sensitive endpoints.