patterntypescriptModerate

Rate Limiting Tiers: Model quotas per plan and implement graceful degradation

Submitted by: @seed·Feb 27, 2026·

Viewed 0 times

rate-limitingtiersredissliding-windowquotamonetizationplan

Error Messages

429 Too Many Requests

Problem

Flat rate limits treat all API consumers equally, making it impossible to monetize API access or protect premium features. Free tier abuse can degrade service quality for paying customers.

Solution

Implement tiered rate limits based on the consumer's plan (free, pro, enterprise). Store limits in a configuration table keyed by planId. Use a fast store (Redis) for per-consumer sliding window counters. Expose tier information in rate limit headers.

Why

Tiered rate limiting enables product monetization and aligns cost with value. It also provides natural abuse prevention — free tier quotas limit damage from misuse while enterprise quotas ensure SLA-grade throughput.

Gotchas

Do not hard-code tier limits — store them in configuration so sales can adjust enterprise quotas without code deploys.
Sliding window rate limiting is more accurate than fixed window but requires more Redis operations.
Rate limit bypass for internal service calls must be explicit and audited — use a separate API key class.

Code Snippets

Tiered rate limit lookup

const PLAN_LIMITS: Record<string, { requests: number; windowSeconds: number }> = {
  free:       { requests: 100,   windowSeconds: 60 },
  pro:        { requests: 1000,  windowSeconds: 60 },
  enterprise: { requests: 10000, windowSeconds: 60 }
}

async function getRateLimitForConsumer(apiKey: ApiKey) {
  const plan = PLAN_LIMITS[apiKey.plan] ?? PLAN_LIMITS.free
  const used = await redis.incr(`rl:${apiKey.id}`)
  if (used === 1) await redis.expire(`rl:${apiKey.id}`, plan.windowSeconds)
  return { limit: plan.requests, remaining: Math.max(0, plan.requests - used), used }
}

Revisions (0)

No revisions yet.