Rate limiting controls the number of requests a client can make to a service within a given time window, protecting against abuse and ensuring fair resource usage. When limits are exceeded, services typically respond with HTTP 429 Too Many Requests along with a Retry-After header. Rate limits can be enforced per user, per API key, per IP address, or globally for an entire service, and can be implemented at the API gateway, load balancer, or application layer.
Several algorithms implement rate limiting. The token bucket algorithm holds tokens in a bucket up to a burst capacity, refills tokens at a fixed rate per second, and consumes one token per request. If the bucket is empty, requests are rejected or queued. Token buckets allow short bursts of traffic up to bucket size, are simple to implement, and smooth out traffic over time, which is why AWS, Stripe, and many other API providers use them.
The sliding window algorithm tracks requests in a continuously moving time window. The sliding window log stores timestamps of all requests, removes timestamps older than the window on each new request, and rejects the request if the count exceeds the limit. The sliding window counter is a hybrid that combines the current and previous fixed window counts, weighting by overlap. Sliding windows are more accurate than fixed windows and avoid the boundary burst problem.
Beyond request throttling, applications often need real-time communication between client and server. WebSockets provide a full-duplex, persistent communication channel over a single TCP connection, starting with an HTTP upgrade handshake and then allowing both sides to send messages at any time. They are ideal for real-time chat, live dashboards, multiplayer games, and collaborative editing, and use the ws or wss (encrypted) protocols. Long polling is an alternative where the client sends an HTTP request and the server holds it open until new data is available or a timeout occurs; the client then immediately reopens the connection. Long polling works everywhere HTTP works without special protocols, but it carries higher latency than WebSockets and forces the server to hold many open connections. Server-Sent Events (SSE) provide a unidirectional push channel from server to client over a single, long-lived HTTP connection using the text/event-stream content type, with built-in browser auto-reconnection. SSE is best for server-push scenarios like live feeds and notifications, while WebSockets are preferable when bidirectional communication is needed.