Challenge 3: Explain the Sliding-Window Pattern — Possible Solution
====================================================================

A sorted set with timestamps as scores fits rate limiting well because
a sorted set is naturally ordered by that score — which, when the
score IS a timestamp, means the set is automatically ordered by TIME.
Each incoming request gets added as a new member (e.g. a unique
request ID) with its arrival timestamp as its score. Because Redis
keeps the set sorted by score at all times, "the oldest entries" and
"the newest entries" are always trivially identifiable ranges within
the set, without needing to sort anything manually.

THE ROLE OF ZREMRANGEBYSCORE: a sliding window (e.g. "no more than 100
requests in the last 60 seconds") needs OLD entries to eventually stop
counting once they age out of that window — otherwise the count would
only ever grow, never reflecting the CURRENT rate. ZREMRANGEBYSCORE
removes every member whose score (timestamp) falls below the cutoff
for "60 seconds ago from right now" — pruning exactly the entries that
have aged out of the window, right before counting.

After pruning, a simple ZCARD (counting remaining members) gives an
accurate count of requests that happened strictly within the current
sliding window — not since the beginning of time, and not based on a
fixed, resettable time bucket (like "requests this calendar minute"),
which is what makes this a genuine SLIDING window rather than a fixed
one: the window continuously moves forward with "now," rather than
resetting at artificial boundaries.