What to Limit By: Keys and Dimensions — Rate Limiting, Quotas & Abuse Protection

The limiter key decides fairness. IP works for anonymous traffic but punishes NAT/corporate users and is easily rotated by attackers (and IPv6 makes per-address limits weak — limit per /64). User/API key/tenant is fairer for authenticated traffic. Combine dimensions: per key per endpoint class (write, search, login), global per tenant, and per-IP for unauthenticated endpoints. Weight by cost for expensive operations.

Limiter keys

Key	Pros	Cons	Use for
IP address (/64 for IPv6)	Works before auth	NAT sharing; rotation	Login, signup, anonymous
User ID	Fair per person	Needs auth	Logged-in actions
API key / client ID	Per integration; ties to plans	Key sharing	Public APIs
Tenant / org	Protects multi-tenant fairness	One user can starve teammates	SaaS-wide caps
Endpoint class	Protect expensive paths	More config	Search, exports, writes
Account + target (e.g. email)	Stops targeted attacks	More keys	Password reset, OTP

Layered limits for an API (example)
- per IP (unauthenticated):      60 req/min
- per API key:                   1,000 req/min (burst 200), writes 100/min
- per tenant (all keys):         5,000 req/min
- search endpoint per key:       60 req/min (cost-weighted)
- login per account + per IP:    5 failures / 15 min

Common pitfalls

IP-only limits for authenticated APIs.
Ignoring IPv6 address abundance.
Trusting X-Forwarded-For from anyone.

Key points

Choose keys for fairness
Layer multiple dimensions
Weight by cost

Further reading: Google Cloud: Rate-limiting strategies

Practice questions

Why limit IPv6 clients per /64 prefix instead of per address?

Answer

A single client typically controls a whole /64 (2^64 addresses) and can rotate addresses trivially, bypassing per-address limits.

Why combine per-key and per-tenant limits?

Answer

Per-key limits stop one integration from bursting; per-tenant limits stop a customer from bypassing limits by creating many keys.