SLIDING WINDOW —

Goal — only n(e.g. 5) requests allowed in m(60) seconds window size .

So for each new request check for requests count within now - window size .

And after adding it to state keep in mind that this request will be a part of future states as well .

At each step (when new reqst arrives) — we need to check if it’s allowed or not ? —> we need count of requests in window size . —> delete any older requests than window size from now .

—> count requests present to check if we can allow new request —> if possible add it —> reset collection of current requests expiry ttl to window size again . —> otherwise with each new request older requests within window size from now will drop out of stored state and new request that we added(and those we add later) will start with a lowered expiry ttl and hence which again kinda turn like fixed window .

Think of it like at each new request addition in stored state we consider it a singular request or each new addition has the behaviour of a new request and reset expiry ttl (of current stored requests until now ) to window size again . —> This also increase expiry ttl of older requests but we will delete older requests (timestamps ≤ now - window size )

Each request gets a live time of window size but we also increase live time of older requests in that window so we need to manually remove older requests than now - window size at first .

It’s like keeping the recent past(window size) context alive and also giving a fair future context to new additions .

—> if the count exceeds limit — deny and don’t reset expiry ttl .

At each point (request) we keep check of 2 things current request is a part of past and future context .

Fixed window each window gets a ttl of 60s , sliding win - each request gets a ttl of 60s