DOC-6349 rate limiter use case example

[andy-stark-redis]

WIP

A simple and partially-implemented use case example for a Redis rate limiter. The code works but the presentation, etc, probably needs some work yet. When we've got a plan together, I'll continue and add the corresponding examples for the other clients.

Some things to think about:

• Maybe we should make the code visible in the page but with a new shortcode for formatting it? It could live in local_examples but maybe get added to the page in a scrollable foldout or something?
• Is it also useful to have the whole set of code downloadable from somewhere (maybe a Github repo with all the use case examples in it?)
• It might be helpful to settle on a standard page structure for the examples, but maybe we need to have at least one more in place to see what they have in common.

All other feedback and suggestions welcome, of course :-)

---

Note

Low Risk
Low risk documentation-only addition; the only functional code is standalone Python demo/reference that doesn’t affect production runtime behavior.

Overview
Introduces a new develop/use-cases docs section and adds an initial Rate limiting use case page describing a Redis/Lua token-bucket algorithm and how to integrate it.

Adds standalone Python reference code: a TokenBucket helper that executes the Lua script via EVALSHA/EVAL and a small HTTP demo server that lets readers interactively test requests and change limiter settings.

^{Written by Cursor Bugbot for commit 617a80f. This will update automatically on new commits. Configure here.}

[github-actions]

DOC-6349

[github-actions]

Staging links:
https://redis.io/docs/staging/DOC-6349-use-case-rate-limiter/develop/use-cases/
https://redis.io/docs/staging/DOC-6349-use-case-rate-limiter/develop/use-cases/rate-limiter/

[jit-ci]

🛡️ Jit Security Scan Results

✅ No security findings were detected in this PR

---

^{Security scan by Jit}

[cursor]

Config update limiter assignment lost between requests

Medium Severity

In _handle_config_update, self.limiter = TokenBucket(...) creates an instance attribute on the current handler, but BaseHTTPRequestHandler creates a new instance for each request. The instance is discarded after the response, so the updated limiter is never used by subsequent requests — they still read the old class-level limiter. Meanwhile, self.config[...] = ... mutations persist because they modify the shared class-level dict in place. This causes a silent mismatch: the displayed config updates but the actual rate limiting behavior doesn't change. It needs to assign to RateLimiterHandler.limiter (the class variable) instead.

 

[dwdougherty]

Just one nitpick. Otherwise, language LGTM. I didn't review code.

I'll give the other things you mentioned some thought, but I don't see why you can't just go ahead and merge this as is (assuming @mich-elle-luna approves as well).

[andy-stark-redis]

@dwdougherty Thanks for spotting that (again!) This is the first time I've done a task with Augment Intent - there might be a way to pass it a link to the style guide as a general preference.

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, have a team admin enable autofix in the Cursor dashboard.}