Protect the expensive resource
Define whether each control protects fairness, financial cost, authentication, a downstream dependency, or overall availability. Weight expensive operations and bound concurrency, payload size, query depth, response volume, and queue length.
Use client, user, tenant, route, and operation as limit dimensions. Source IP remains useful at the unauthenticated edge but is too coarse to carry the full policy.
Layer edge and application controls
Use upstream network protection for volumetric attacks, gateways for parsing and route policy, applications for business-aware limits, and bulkheads for dependencies. Restrict direct origin access so attackers cannot bypass the protected edge.
Treat alternate domains, IPv6 paths, admin ports, health endpoints, and message interfaces as part of the same exposure map.
Handle overload predictably
Return stable error codes and useful retry guidance. Encourage exponential backoff with jitter. Use idempotency controls for safe retries of state-changing requests, while limiting the idempotency store itself.
Predefine graceful degradation and lockdown modes that preserve essential operations without weakening authentication or authorization. Make activation, scope, owner, and rollback auditable.
Measure fairness and recovery
Monitor weighted cost, in-flight work, queue depth, rejection reasons, saturation, dependency health, and false positives by client and tenant. A global average can hide that one customer is completely blocked.
Load-test uneven tenants, slow dependencies, retry storms, counter-store failure, direct-origin traffic, and restoration after emergency controls.
Implementation checklist
- Tie limits to a stated protection goal.
- Key budgets by identity, tenant, route, and cost.
- Bound concurrency, payloads, queries, and queues.
- Restrict direct access around edge controls.
- Define safe degradation and lockdown modes.
- Test retries, dependency loss, and restoration.
Frequently asked questions
Is rate limiting the same as DDoS protection?
No. Rate limiting is one control. DDoS resilience may also require upstream capacity, protocol protection, origin restriction, application cost controls, dependency bulkheads, and incident procedures.
Should an API fail open if the rate-limit store is down?
The answer depends on the endpoint and risk. Use local safety limits and bounded fallbacks; an unlimited fail-open path can remove protection during instability.
What is a lockdown API mode?
It is a predefined incident state that narrows routes, clients, or operations to preserve critical service and contain abuse. It should be tested, time-bounded, monitored, and reversible.
