forge-rate-limiting

What problem does it solve?

This Skill prevents overload, abuse, and thundering herds by ensuring your service rate-limits requests correctly across deployments and replicas rather than using fragile in-memory counters.

Core Features & Use Cases

• Correct identity-based limiting: Choose per-route rate-limit keys (IP, user, token, tenant) so you protect the right actors without locking out legitimate users.
• Right window algorithm by use case: Use token bucket as default, sliding window for per-second precision, and fixed window only for low-volume endpoints.
• Distributed enforcement with Redis: Implement canonical Redis-backed token buckets (Lua-based) so all replicas share the same counters.
• Operationally correct responses: Always emit rate-limit headers on every response and return 429 with a proper Retry-After to enable safe client pacing.
• Incident-ready configuration: Keep rate-limit settings hot-reloadable instead of hardcoded so you can tighten limits during an incident.
• Client retry hygiene: Ensure retry behavior honors server-provided Retry-After to avoid synchronized retry storms.

Quick Start

Use forge-rate-limiting to design or audit your service’s rate limiting so every response includes rate-limit headers and any 429 response includes a correct Retry-After for a Redis-backed token-bucket policy keyed appropriately per endpoint.