Sliding window vs fixed window rate limiting: what the difference actually costs you

A fixed window rate limiter has an exploitable boundary: vote at 11:59pm, vote again at 12:00am — two votes in two minutes, both within their respective windows. A sliding window tracks the rolling 24 hours and has no such boundary. For AI Art Arena, where one vote per person per contest is the core integrity guarantee, only one of these is acceptable.

Why fixed window fails at boundaries

A fixed window rate limiter works like this: you have a bucket that allows N requests. The bucket resets at a fixed interval — say, every 24 hours at midnight. The problem is the reset boundary.

Upstash Ratelimit uses the approximate sliding window algorithm — two counters, weighted by how far into the current window you are. It's not perfectly accurate at the exact window boundary, but the error margin is under 1% and it uses constant memory regardless of request volume.

How the vote rate limiter is keyed

The key design is as important as the algorithm. Keying by IP alone is too weak. Keying by user ID alone misses anonymous visitors. The solution is to use the strongest available identifier, with a fallback:

// lib/ratelimit.ts
export function buildVoteRateLimitKey(
  email: string | null | undefined,
  ipHash: string,
  contestId: string
): string {
  const salt = process.env.VOTE_HASH_SALT;
  if (!salt) throw new Error('VOTE_HASH_SALT env var is required');

  if (email) {
    // Authenticated users: keyed by email hash — survives IP changes, VPNs, device switches
    const emailHash = crypto
      .createHash('sha256')
      .update('email:' + email.toLowerCase().trim() + salt)
      .digest('hex')
      .slice(0, 32);
    return `${emailHash}:${contestId}`;
  }

  // Anonymous visitors: keyed by IP hash — best available signal
  return `${ipHash}:${contestId}`;
}

The VOTE_HASH_SALT problem — why you can never change it

Both the rate limiter and the database use hashed email as a duplicate-vote signal. The hash uses VOTE_HASH_SALT as a secret input. This creates a critical constraint: if you change the salt after launch, all existing hashes in Redis and in the votes table become orphaned. The system loses its ability to detect that alice@example.com already voted — her new hash doesn't match her old one.

Five rate limiters, not one

Vote rate limiting is one of five limiters running in the application. Each is tuned independently to its threat model:

All five use Upstash's serverless Redis — no persistent connection management, compatible with Vercel's edge and serverless functions, and analytics built in so you can see hit/miss ratios in the Upstash console without additional instrumentation.

From the build log