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.
In this repository73 other files it gives its agents.
- AGENTS.mdAGENTS.md
- bigquery-analyticsSkill
- cache-invalidationSkill
- mongo-aggregationSkill
- mongo-modelingSkill
- postgres-aggregationSkill
- postgres-indexingSkill
- redis-patternsSkill
- review-querySkill
- code-migrationSkill
- cut-releaseSkill
- data-migrationSkill
- deploy-serviceSkill
- hotfixSkill
- rollbackSkill
- design-endpointSkill
- design-eventSkill
- design-schemaSkill
- evolve-contractSkill
- scaffold-nestjs-moduleSkill
- scaffold-projectSkill
- incident-responseSkill
- investigate-bugSkill
- on-callSkill
- postmortemSkill
- audit-skillsSkill
- distill-review-styleSkill
- write-skillSkill
- debug-with-tracesSkill
- define-alertsSkill
- instrument-serviceSkill
- evaluate-dependencySkill
- grillSkill
- handoffSkill
- orientSkill
- phased-deliverySkill
- spikeSkill
- to-questionnaireSkill
- write-adrSkill
- write-prdSkill
- devops-pr-reviewSkill
- go-backend-pr-reviewSkill
- nestjs-backend-pr-reviewSkill
- python-backend-pr-reviewSkill
- react-frontend-pr-reviewSkill
- bisectSkill
- break-couplingSkill
- dead-code-sweepSkill
- deslopifySkill
- extract-moduleSkill
- rebase-cleanSkill
- resolve-merge-conflictsSkill
- split-commitSkill
- tddSkill
- wait-whatSkill
- wide-renameSkill
- bullmqSkill
- kafkaSkill
- sqs-consumerSkill
- audit-dependenciesSkill
- The first 60 shown.
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
- Very specific: line 45
All counters via Lua (atomic read-modify-write.
≈ “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.
Files
Redis coordination — locks & rate limits
First: do you need a distributed lock?
Often the answer is no. Prefer, in order:
- A DB unique constraint / upsert — let the database enforce "only one".
- An idempotency key — make the operation safe to run twice instead of preventing the second run.
- A single-writer design — partition work so only one worker owns a key.
- 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 — neverSETNXthenEXPIRE(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):
| Algorithm | Shape | Note |
| Fixed window | INCR key, EXPIRE on first, reject if > limit | simplest; allows 2× burst at window edges |
| Sliding window log | sorted set of timestamps, ZREMRANGEBYSCORE old, count | accurate, more memory |
| Sliding window counter | weighted blend of current + previous fixed window | good accuracy/cost balance |
| Token bucket | stored tokens + last-refill timestamp, refill on read | allows 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+EXPIREas 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
INCRthen compare for rate limiting. - ❌ Rate-limit counter reads off a replica.
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
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.

