←

Sliding-window rate limiter (logical clock)

seniorjava · AI-on
  1. 1Restate the problem in one line
  2. 2Sketch the data model yourself
  3. 3Ask AI for a skeleton ONLY
  4. 4Ask AI for a test plan ONLY
  5. 5Implement the core logic yourself
  6. 6Run the tests — verify, don't trust
  7. 7Ask AI for edge cases you missed
  8. 8Ask AI to review your code
  9. 9Make the final judgment yourself

Problem

Build a per-key sliding-window rate limiter. The constructor takes a limit and a windowMs. allow(key, now) returns true if the request at logical time now (in ms) is within the limit for that key, counting only the allowed requests in the trailing window of length windowMs; otherwise it returns false. Denied requests must not consume a slot. Time is always supplied by the caller — no Thread.sleep, no system clock.

iThe deal with the pair partner

The AI is deliberately fallible — it gives hints, not solutions, and sometimes proposes wrong code. It cannot touch your editor. Paste what you choose, then Run. Anything AI-derived stays UNVERIFIED until your tests go green.

Self-check

  • ☐the first `limit` requests for a key inside one window are allowed
  • ☐the next request in the same window is denied
  • ☐each key tracks its own budget independently
  • ☐a denied request does not record a timestamp / consume a slot
  • ☐old timestamps fall out of the window so the budget refills over logical time
  • ☐you used the caller-supplied `now` only (no System.currentTimeMillis / sleep)
Hints / what this doesn't test

This is an Opendoor-flavored applied problem: a stateful policy component tested with a logical clock, so it stays deterministic. Restate it first — "So allow is called with the current time, I count only the requests I admitted in the last windowMs, and a rejected call shouldn't count against the next one?"

What this problem does not test (say so out loud): the cheaper fixed-window counter (and its boundary-burst flaw), a token-bucket variant, eviction of idle keys to bound memory, and concurrency are out of scope here — but a senior names that admitting before the window check, or recording denied requests, are the two classic off-by-one bugs in this shape.

Solution.javaauto-runs ~0.8s after you pause
unverifiedEdited since last clean run — run to verify.

Tests

○ Not run yet — edit the code or press Run
  • ○under_limit
  • ○over_limit
  • ○per_key_isolation
  • ○window_slides
  • + 2 hidden tests — revealed once the visible ones pass

Pair partner (병신 모드 · 버그 잡기)

gpt-4o-mini

Ask for a skeleton or a test plan — not the answer. Then implement the core yourself and come back for edge cases. Remember: the partner is fallible. Verify everything by running it.

The partner sees your editor but cannot change it. Copy any suggestion in by hand, then Run to verify.

AI랑 먼저 페어하고 눌러