API Rate Limiting: Sådan beskytter du din backend

Din API er live. Trafikken stiger. Pludselig rammer nogen dit endpoint 10.000 gange på ét minut. Hvad sker der?

Uden rate limiting: Din server går ned, dine ægte brugere kan ikke tilgå tjenesten, og du får en sur morgen.

Med rate limiting: Misbrugeren får en pæn 429 Too Many Requests, og alle andre kører videre som normalt.

Hvad er rate limiting?

Rate limiting begrænser hvor mange requests en klient kan sende inden for et tidsrum. Det er din første forsvarslinje mod:

• DoS-angreb - forsøg på at overbelaste din server
• Brute force - login-forsøg der gætter passwords
• Scraping - bots der høster dine data
• Utilsigtede loops - buggy klient-kode der spammer

De fire klassiske algoritmer

1. Fixed Window

Den simpleste tilgang. Tæl requests i faste tidsintervaller (f.eks. per minut).

Fordele:

• Super simpel at implementere
• Lav memory-overhead

Ulemper:

• "Burst problem" - en bruger kan sende 100 requests kl. 12:59 og 100 mere kl. 13:00, altså 200 requests på 2 minutter mens grænsen er 100/minut

2. Sliding Window

Løser burst-problemet ved at tracke requests over en glidende tidsperiode.

Fordele:

• Jævnere fordeling af requests
• Ingen edge-case ved window-skift

Ulemper:

• Kræver mere memory (timestamps per request)
• Lidt mere kompleks at implementere

Dette er vores foretrukne valg til de fleste use cases.

3. Token Bucket

Tænk på det som en spand med tokens. Hvert request bruger ét token. Spanden fyldes op med en fast rate.

Fordele:

• Tillader bursts (hvis spanden er fuld)
• Modellerer realistisk brugeradfærd

Ulemper:

• Mere kompleks state management

Perfekt til API'er hvor brugere naturligt har perioder med inaktivitet efterfulgt af bursts.

4. Leaky Bucket

Requests kommer ind i en kø og behandles med konstant hastighed, som vand der drypper fra en spand.

Fordele:

• Garanteret jævn belastning på serveren
• Ingen pludselige spikes

Ulemper:

• Kan føles langsomt for brugeren
• Requests kan queue op og skabe latency

Bruges ofte til betalings-API'er og andre kritiske systemer.

Hvilken algoritme skal du vælge?

Implementering i praksis

HTTP Response Headers

Fortæl altid klienten hvad der sker:

HTTP/1.1 200 OK
X-RateLimit-Limit: 100
X-RateLimit-Remaining: 42
X-RateLimit-Reset: 1704830400

Når grænsen nås

HTTP/1.1 429 Too Many Requests
Retry-After: 60
Content-Type: application/json
 
{
  "error": "rate_limit_exceeded",
  "message": "Du har sendt for mange requests. Prøv igen om 60 sekunder.",
  "retry_after": 60
}

Tiered Rate Limits

Ikke alle brugere er ens. Differentier dine limits:

Per-Endpoint Limits

Nogle endpoints er dyrere end andre:

const limits = {
  'GET /users': { max: 100, window: '1m' },
  'POST /upload': { max: 10, window: '1m' },
  'POST /ai/generate': { max: 5, window: '1m' },
};

Hvor implementerer du det?

1. API Gateway (anbefalet)

Cloudflare, AWS API Gateway, Kong, eller Nginx håndterer det før din kode overhovedet kører.

Fordele: Skalerbart, distribueret, ingen kode-ændringer.

2. Middleware

Express, Fastify, eller dit frameworks middleware-lag.

import rateLimit from 'express-rate-limit';
 
const limiter = rateLimit({
  windowMs: 60 * 1000, // 1 minut
  max: 100,
  standardHeaders: true,
  message: { error: 'For mange requests' }
});
 
app.use('/api/', limiter);

3. Database/Redis

Brug Redis for distribueret rate limiting på tværs af flere servere:

// Simpel sliding window med Redis
const key = `ratelimit:${userId}:${endpoint}`;
const count = await redis.incr(key);
if (count === 1) {
  await redis.expire(key, 60);
}
if (count > 100) {
  throw new RateLimitError();
}

2026-trend: AI-drevet rate limiting

Med flere AI-agenter der kalder API'er, ser vi en ny tilgang:

• Behavior analysis - ikke bare tæl requests, men analyser mønstre
• Threat scoring - dynamisk justering baseret på risiko
• Adaptive limits - automatisk skalering under load

Dette er stadig tidligt, men hold øje med værktøjer fra Cloudflare og Kong.

Vores anbefaling

For de fleste projekter:

1. Start med en API gateway (Cloudflare er gratis for basics)
2. Brug Sliding Window som default-algoritme
3. Implementer tiered limits fra dag ét
4. Log alt - du vil takke dig selv senere

Rate limiting er ikke kun sikkerhed. Det er også dokumentation af din API's kapacitet og en måde at beskytte din infrastruktur-budget på.