Add rate limiting

Step by step

1. 1

   Decide what to protect and at which layer

   List the endpoints that are expensive or abusable: login/signup, password reset, email/SMS send, payment, and anything that calls an LLM. Cheap read endpoints usually don't need it. If you can rate limit at the edge (Vercel Firewall, Cloudflare, Arcjet) do that first — it blocks abuse before it costs you compute; use app-level limiting for finer, per-user rules.

2. 2

   Pick a shared store, not process memory

   On Vercel/serverless or any horizontally-scaled host, a `Map` or module-level variable is per-instance and resets on cold start — useless. Provision Upstash Redis (serverless, HTTP-based, works from edge functions) or any Redis you already run. Managed API-key products like Unkey or Arcjet bundle the store so you skip this.

3. 3

   Choose the algorithm

   Use a sliding-window limiter for most cases — it avoids the burst-at-the-boundary problem that fixed windows have (100 req allowed at 11:59:59 and another 100 at 12:00:00). `Ratelimit.slidingWindow(10, '10 s')` reads as '10 requests per 10 seconds'. Reserve token-bucket for APIs that need to allow short bursts.

4. 4

   Choose your key carefully

   Prefer a stable identity: the authenticated user ID (e.g. Clerk `userId`) or API key. Fall back to IP only for unauthenticated traffic. IP is weak — carrier NAT and corporate networks share one IP across many users, and `x-forwarded-for` can be spoofed unless you read the trusted client IP your platform sets. Never trust a raw header blindly behind a proxy.

5. 5

   Enforce and return 429 correctly

   When `success` is false, respond `429 Too Many Requests` with a `Retry-After` header (seconds until reset) and ideally `X-RateLimit-Remaining`/`X-RateLimit-Reset`. Libraries, browsers, and mobile clients back off automatically when you send these — omit them and clients just keep retrying.

6. 6

   Fail open, add per-route limits, then test

   Wrap the limit check so that if Redis is unreachable your app allows the request rather than 500ing every user — a rate limiter should never be a single point of failure for the whole app (unless the endpoint is security-critical, then fail closed). Give tight limits to sensitive routes and loose ones to the rest. Verify with a quick loop: `for i in $(seq 1 20); do curl -s -o /dev/null -w '%{http_code}\n' https://localhost:3000/api/send; done` and confirm you see 200s flip to 429s.

// lib/ratelimit.ts
import { Ratelimit } from "@upstash/ratelimit";
import { Redis } from "@upstash/redis";

export const ratelimit = new Ratelimit({
  redis: Redis.fromEnv(),           // reads UPSTASH_REDIS_REST_URL/TOKEN
  limiter: Ratelimit.slidingWindow(10, "10 s"), // 10 req / 10s
  analytics: true,
  prefix: "@myapp/ratelimit",
});

// app/api/send/route.ts
import { ratelimit } from "@/lib/ratelimit";
import { auth } from "@clerk/nextjs/server";

export async function POST(req: Request) {
  const { userId } = await auth();
  // Prefer a stable identity; fall back to IP for anon traffic.
  const key = userId ?? req.headers.get("x-forwarded-for") ?? "anon";

  const { success, remaining, reset } = await ratelimit.limit(key);
  if (!success) {
    return Response.json(
      { error: "Too many requests" },
      {
        status: 429,
        headers: {
          "Retry-After": String(Math.ceil((reset - Date.now()) / 1000)),
          "X-RateLimit-Remaining": String(remaining),
        },
      }
    );
  }

  // ...do the expensive work (send the email, call the LLM, etc.)
  return Response.json({ ok: true });
}