PraxisAI
Sign in
Infrastructuremedium

Rate limiter library and HTTP middleware

Token bucket and sliding window behind one interface, pluggable stores, injectable clock, and 429 middleware with Retry-After.

Suggested effort
~4h focused work
Window
24 hours
Starts from
An empty repo
Stack
Your choice
Sign in to start this build →

Opens in a new tab. The clock starts when you press Start inside the environment, not before, and your workspace is kept while you step away.

Time window 24 hours. Suggested effort about 4 hours.

Context

The platform team needs a reusable rate limiter for its HTTP services: per API key, configurable, and honest with clients about when to retry.

Core requirements

  • A library with two algorithms behind one interface: token bucket and sliding-window log (or sliding-window counter).
  • An in-memory store, and a store interface so a shared store (for example Redis) can be added without touching the algorithms.
  • HTTP middleware for one framework: identifies the caller by the X-API-Key header (falling back to IP), applies per-route limits from a config file, and returns 429 with Retry-After and RateLimit-* headers.
  • A small demo server with two routes that have different limits.
  • Time is injectable (a clock interface) so behaviour is testable without sleeping.

Acceptance criteria

  • Tests with a fake clock prove: bursts up to the bucket size pass, the next request is rejected, and capacity refills at the configured rate; the sliding window does not allow double the limit across a window boundary.
  • Concurrent requests (for example 100 at once against a limit of 10) admit exactly 10; the test proves it.
  • Memory does not grow without bound for many distinct keys (idle keys are evicted; explain the policy).
  • The README compares the two algorithms and says when you would choose each.

Stretch goals (optional)

  • A Redis store using an atomic script, with tests against a local Redis (skipped if none is running).
  • Hot reload of the limits file.
  • A load-test script and its results.

Constraints

  • Any language. Suggested: Go, TypeScript (Node) or Python.

Deliverables (every project)

  • Source code committed in this repository (the grader diffs against the first commit).
  • README.md that replaces the stub, with: how to install, run and test it (copy-pasteable commands); the decisions and trade-offs you made; what you would do next with more time; and a short note on how you used the AI agent (what you delegated, what you checked or rewrote).
  • Automated tests that run with a single command (npm test, pytest, go test ./... or cargo test).
  • No secrets in the repository. Anything configurable reads from environment variables with safe defaults.

Ground rules

  • The 24-hour clock is a window, not a workload. Stop at roughly the suggested effort, then write down what you would do next. A small, finished, tested core beats a large unfinished one.
  • Use the AI agent as much or as little as you like: every prompt is recorded and the report shows how it was used. You are judged on the result and on whether you understood and verified what the agent produced.
  • The work is yours. PraxisAI uses it only to produce your assessment report.