Fixed-window rate limits hand an attacker 200 requests in two seconds

Run the attack in that post against the fix in the same post and you get a number it does not print. One second into the new window the weight is 59/60, so the previous minute's 100 hits are still carried as 98 ^[8]. The check refuses as soon as the estimate reaches the limit, which leaves room for exactly two more requests: 102 across the boundary instead of 200 ^[3]. That is the real case for the change, stated as arithmetic rather than as "Boundary Smoothness" ^[14], and the same arithmetic shows what is being bought, which is a bounded error rather than a correct count.

The error has a direction. The weight depends only on how far into the current window you are, never on where in the previous window the requests actually landed ^[8]. A client that made its 100 calls in the first second of 12:00 is still charged 98 of them at 12:01:01, and collects a 429 on its third request of a minute it has barely entered ^[12][3]. Fixed windows are permissive at the boundary and the weighted counter is punitive at the same boundary. For a login form, punitive is the right way round. The post names payment paths alongside auth as the motivation ^[5] without separating them, and those two do not want the same failure direction.

The complexity claims deserve the same literalism. Exact counting with a timestamp deque is O(N) space ^[6] and the two-integer version is O(1) ^[10], but O(1) is per key. The published class holds one record per client IP in an in-process Map, the key is read from req.ip or the x-forwarded-for header, and the code as shown never removes an entry ^[11]. Memory therefore tracks the number of distinct keys the endpoint has ever been shown, a quantity set by whoever is calling rather than by the operator.

Inside one process that is a housekeeping problem. Across several app instances it is an arithmetic one: each process keeps its own two counters ^[11], so a limit configured as 100 is enforced once per instance, and eight instances behind a load balancer admit 800 per minute before anything says no ^[4]. The 102 figure only holds once the counters are shared. Until then the weighted limiter is a fixed-window limiter with better manners, and the difference between 200 and 102 sits on a Redis deployment the post asserts rather than demonstrates ^[13].