It’s 9 PM. The rate limiter ships tomorrow.
Alex has forty Stack Overflow tabs open, a chat that stopped making sense at message thirty, and a demo in twelve hours. The one diff that mattered is buried six edits deep.
She closes the tab. Starts over — differently.
One task, explored differently.
The fork
Section two holds the claim her fix depends on. Do what Alex did — select the sentence.
Fixed windows let a client send double its limit in the two seconds either side of the reset.
At a 100 requests/minute limit, a client can send 100 requests at 11:59:59 — the tail of one window — and another 100 at 12:00:01, the head of the next: 200 requests in two seconds against a stated 100/minute cap. The fix in this branch is a Redis-backed sliding window counter — it keeps the current bucket’s count plus a weighted fraction of the previous bucket’s, so the effective limit degrades smoothly across the boundary instead of resetting to zero. Cost: one extra GET per request, still O(1).
In production the sliding-window counter has to be atomic across replicas — a naive GET-then-INCR from two API instances can race, and both can pass a check that should have failed one of them. The fix is a single Redis Lua script (EVAL) that reads the previous bucket, computes the weighted count, and increments the current bucket in one round trip, so the check-and-increment can’t interleave. Clock skew between app servers is the usual failure mode in review: if two instances disagree on which 60-second bucket a request falls into by even a second, users near the boundary get double- or under-counted. Redis’s own TIME command sidesteps this by using the server’s clock instead of each app instance’s.
The right brain for the branch
In production the sliding-window counter has to be atomic across replicas — a naive GET-then-INCR from two API instances can race, and both can pass a check that should have failed one of them. The fix is a single Redis Lua script (EVAL) that reads the previous bucket, computes the weighted count, and increments the current bucket in one round trip, so the check-and-increment can’t interleave. Clock skew between app servers is the usual failure mode in review: if two instances disagree on which 60-second bucket a request falls into by even a second, users near the boundary get double- or under-counted. Redis’s own TIME command sidesteps this by using the server’s clock instead of each app instance’s.
The branch that matters gets the sharper mind. She’s paying per thought, not per month.
Receipts
It adds a Redis-backed sliding-window counter in a new rate limiter module. It writes a matching test file covering the boundary case where fixed windows used to double-count. It wires the middleware into the Express app ahead of the existing routes. The first run fails on a TTL type mismatch — FAIL — the fix casts the argument to a number, and the suite goes green: PASS.
Two hours. Not a transcript — a map.
Every step reviewable. No mega-diff.
The merge
She stops branching and starts merging. Every thread that mattered, one PR:
It survives the night
Monday morning: she reopens the project from Projects. Same map, same commits, exactly where she left them.
Adds per-user rate limiting to the API with a Redis-backed sliding-window counter. Fixes the boundary-burst issue where fixed windows let a client send up to 2x its limit across a reset.
Reopen it anytime — the whole map, every commit, is still there.
№4 — It ends as a reviewable PR, not a transcript you’ll never reopen.
The bill
“No subscription was harmed.”
Illustrative estimate — actual cost varies with models and task complexity.
Price your own nights
Estimate based on a typical multi-section answer (~1,500 input / ~2,800 output tokens) — your mileage will vary with task complexity and model choice. Not a guarantee.
Fine print
Yes — forkai code needs a free account to start a project. Your first $5 of usage is on us, no card required.