agentleFS
tejastn10tejastn10/workbench/skills/data/redis-coordination/SKILL.md

redis-coordination

Skill1 starsChanged 2 months agoMITView on GitHub

Use Redis for distributed locks and rate limiting correctly — single-instance SETNX+TTL with a fencing token, lock renewal, Redlock caveats, and atomic rate limiters (fixed window, sliding window, token bucket) via Lua. Know when a DB constraint or idempotency key is the better tool. Use when asked for a "distributed lock" / "mutex" / "rate limiter", or when reviewing one.

The file

We split this skill into the rules it gives an agent

1 rule. About 0 are common, 0 are distinctive, and 1 is very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈0

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 1

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    All counters via Lua (atomic read-modify-write.

    line 45

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Redis coordination — locks & rate limits

First: do you need a distributed lock?

Often the answer is no. Prefer, in order:

  1. A DB unique constraint / upsert — let the database enforce "only one".
  2. An idempotency key — make the operation safe to run twice instead of preventing the second run.
  3. A single-writer design — partition work so only one worker owns a key.
  4. Then a Redis lock, accepting it's best-effort.

Redis lock (single instance)

SET lock:<resource> <random-token> NX PX <ttl-ms>
  • NX (only if absent) + PX (TTL) in one command — never SETNX then EXPIRE (crash between = permanent lock).
  • The value is a unique token the holder generated. To release, a Lua script checks the token matches before DEL — so you never delete someone else's lock that you acquired after your TTL expired.
  • TTL < the work it protects? Either the work must be idempotent (the lock is advisory), or renew the lock (a watchdog extending the PX while work continues) — and stop work immediately if a renewal fails.
  • Fencing token — for correctness under GC pauses / network delays, the lock hands out a monotonically increasing token; the protected resource rejects writes with a stale token. Without this, no Redis lock is safe against a paused holder.

Redlock (multi-instance)

The multi-node algorithm exists but is contested (Kleppmann vs antirez). Use it only if you understand the trade-off; for most cases a single-instance lock + fencing token + idempotent work is enough, and simpler.

Rate limiting

All counters via Lua (atomic read-modify-write; a non-atomic INCR-then-check races):

AlgorithmShapeNote
Fixed windowINCR key, EXPIRE on first, reject if > limitsimplest; allows 2× burst at window edges
Sliding window logsorted set of timestamps, ZREMRANGEBYSCORE old, countaccurate, more memory
Sliding window counterweighted blend of current + previous fixed windowgood accuracy/cost balance
Token bucketstored tokens + last-refill timestamp, refill on readallows controlled bursts
  • Key by the limited dimension: ratelimit:<userId>:<route>.
  • Counter reads/writes go to the primary (replica lag undercounts).
  • Return 429 + Retry-After + X-RateLimit-* headers.

Anti-patterns

  • ❌ A distributed lock where a unique constraint would do.
  • ❌ SETNX + EXPIRE as two commands.
  • ❌ Releasing a lock without checking the token.
  • ❌ A lock with a TTL shorter than the work and no renewal and non-idempotent work.
  • ❌ Non-atomic INCR then compare for rate limiting.
  • ❌ Rate-limit counter reads off a replica.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.