API Rate Limiting & Quota Designer

## CONTEXT
I need to protect my API from abuse and overload while staying fair to legitimate clients, and I want a deliberate rate-limiting and quota design for 2026. Rate limiting is deceptively subtle: the algorithm choice (token bucket, sliding window, fixed window) changes burst behavior, the scope (per-key, per-IP, per-endpoint, per-tenant) changes fairness, and the client-facing semantics (headers, status codes, retry guidance) determine whether integrators handle limits gracefully or hammer me harder. I want a coherent policy that defends availability, supports tiered plans, and gives clients everything they need to back off correctly.

## ROLE
Act as a platform reliability engineer who has tuned rate limiting for an API under real abuse and real traffic spikes. You balance protection against legitimate-user friction and design limits that clients can actually respect.

## RESPONSE GUIDELINES
- Start by recommending an algorithm and limiting dimensions for my traffic profile.
- Justify the algorithm choice in terms of burst tolerance and fairness.
- Specify exact response headers, status code, and retry semantics with examples.
- Separate short-term rate limits from longer-term quotas explicitly.
- Address both the enforcement mechanics and the client communication contract.

## TASK CRITERIA

### 1. Algorithm & Limit Modeling
- Compare token bucket, leaky bucket, sliding, and fixed window for my needs.
- Recommend a primary algorithm and explain its burst and smoothing behavior.
- Define limit dimensions (key, tenant, IP, endpoint) and their precedence.
- Decide on global vs per-resource limits and how they compose.

### 2. Tiering & Quotas
- Design plan tiers with distinct rate and quota allowances.
- Distinguish rate (per second/minute) from quota (per day/month) clearly.
- Address quota reset semantics, rollover, and overage handling.
- Recommend how to handle bursty but low-average legitimate workloads.

### 3. Client-Facing Semantics
- Specify the 429 response body and the RateLimit standard headers.
- Define Retry-After behavior and how clients should compute backoff.
- Document how clients discover their current usage proactively.
- Provide guidance text clients can implement for graceful degradation.

### 4. Enforcement Architecture
- Recommend where limiting runs (edge, gateway, service) and the tradeoffs.
- Address distributed counter accuracy versus performance (eventual vs exact).
- Specify the data store for counters and its failure behavior under outage.
- Design fail-open vs fail-closed policy for the limiter itself.

### 5. Abuse Defense & Tuning
- Distinguish rate limiting from abuse/bot mitigation and how they layer.
- Recommend dynamic or adaptive limits for detected abuse patterns.
- Define metrics to tune limits and detect false positives on real users.
- List anti-patterns (silent drops, inconsistent windows) to avoid.

## ASK THE USER FOR
- Typical and peak traffic, plus the shape of bursts you observe.
- Whether you have paid tiers and how they should differ in limits.
- Your gateway/edge stack and available shared storage for counters.
- The abuse you are most worried about (scraping, credential stuffing, cost).