The sliding window log pattern is the most accurate rate limiter you can build. Instead of counting requests in buckets, you store the exact timestamp of every request within the window. When a new request arrives, you drop timestamps older than the window boundary, count what's left, and either admit or reject based on the limit.

Contrast this with its cheaper cousins. Fixed window resets a counter every N seconds — cheap, but a client can hammer you at the boundary. Sliding window counter approximates by weighting the current and previous bucket — off by 10-20% under bursty loads. Sliding window log has zero approximation error: if the limit is 100 requests per minute, you allow exactly 100.

The tradeoff is memory. Every allowed request stores a timestamp. At 1,000 users each hitting 100 req/min, you're storing 100,000 timestamps continuously. In Redis, each 8-byte timestamp in a sorted set costs roughly 80–100 bytes of overhead. That's 10 MB just for rate-limit state — and it grows linearly with your allowed traffic.

Real-world example: Stripe's API rate limiter. When you hit their 100 requests/second limit, they use a Redis sorted set keyed per API token. Each request does:

• ZREMRANGEBYSCORE key 0 (now - window) — evict old entries
• ZCARD key — count remaining
• If under limit: ZADD key now now and EXPIRE key window

Three commands, pipelined, sub-millisecond. The EXPIRE matters: idle keys must self-clean or you leak memory forever.

Rule of thumb for memory sizing: bytes ≈ (limit × active_clients × 100). If you're rate-limiting 100 req/min per user across 50,000 active users, budget ~500 MB of Redis. If that number scares you, switch to sliding window counter — you'll trade 1% accuracy for 100× less memory.

When to actually use it:

• Small client populations where precision matters (partner APIs, paid tiers)
• Compliance-driven limits ("exactly 5 login attempts per hour")
• Debugging aid — the log itself is auditable evidence of what happened

When to avoid it: public endpoints with millions of anonymous clients, high-frequency limits (10K req/sec per key), or any case where an approximation is acceptable. The memory footprint will eat you before the accuracy ever pays off.

One subtle gotcha: use monotonic timestamps, not wall-clock. NTP jumps backward will cause you to accept requests you should have rejected, or worse, evict entries you needed to keep.