---
title: "Comment by Mike Dabydeen on \"Distributed Rate Limiting: Your Effective Limit Isn't Your Config\" | Hashnode"
description: "I'd have the Lua script return the wait time, because window minus elapsed tells a refused client the wrong thing about a sliding window. With the weighted esti"
url: "https://hashnode.com/posts/distributed-rate-limiting-effective-limit/6af6977ee0fa0b84b693d1e2/comment/6af70049f758036b040a3fed"
---

[Discussion](https://hashnode.com/posts/distributed-rate-limiting-effective-limit/6af6977ee0fa0b84b693d1e2)

Comment [Distributed Rate Limiting: Your Effective Limit Isn't Your Config](https://hashnode.com/posts/distributed-rate-limiting-effective-limit/6af6977ee0fa0b84b693d1e2)

[Mike Dabydeen](https://hashnode.com/@firelinks)

[10h ago](https://hashnode.com/posts/distributed-rate-limiting-effective-limit/6af6977ee0fa0b84b693d1e2/comment/6af70049f758036b040a3fed)

I'd have the Lua script return the wait time, because window minus elapsed tells a refused client the wrong thing about a sliding window. With the weighted estimate, capacity comes back gradually, at prev/window per second, about 1.7 requests per second in your 100-per-minute example. A client refused because of last window's weight is often allowed again within a second or two, yet Retry-After sends it to the boundary. Every client refused during that minute gets the same boundary, so they all come back together, and the edge burst you removed returns through the retry path.

Inside the script, when estimate >= limit and prev > 0, the wait is (estimate - limit) \* window / prev, rounded up with a one-second minimum and capped at the time left in the window. One small thing in the caller too: int() truncates, so a client refused at 30.4 seconds is told 29 and arrives just before the reset. math.ceil fixes that.