← Back to all products

Redis Patterns Library

$29

Caching strategies, pub/sub patterns, rate limiting, session management, and Redis cluster configuration templates.

📁 26 files

MarkdownShellPythonRedis

📄 Product Preview

Try the interactive reader and demo tools below, or get the full product with all content unlocked.

📖 Interactive Reader (Free Preview) ⚙ Try Demo Tools 📦 Download Free Sample

📁 File Structure 26 files

redis-patterns-library/ ├── LICENSE ├── README.md ├── config/ │ └── redis.conf ├── docs/ │ ├── caching-strategies.md │ ├── distributed-locks.md │ ├── leaderboards-and-sorted-sets.md │ ├── pubsub-and-streams.md │ ├── rate-limiting.md │ └── ttl-and-eviction.md ├── examples/ │ ├── distributed_lock.py │ ├── rate_limiter.py │ ├── redis_client.py │ └── sample_data.redis ├── free-sample.zip ├── guide/ │ ├── 01_who-this-is-for.md │ ├── 02_how-to-run.md │ ├── 03_file-by-file-guide.md │ └── 04_license.md ├── index.html ├── lua/ │ ├── acquire_lock.lua │ ├── release_lock.lua │ ├── sliding_window.lua │ └── token_bucket.lua └── scripts/ ├── cache_aside_demo.sh ├── leaderboard_demo.sh └── streams_consumer_group.sh

📖 Documentation Preview README excerpt

Redis Patterns Library

A working reference for the Redis usage patterns that show up again and again in

real systems: caching, rate limiting, distributed locks, pub/sub, streams, and

sorted-set leaderboards — plus the memory and eviction tuning that keeps them

healthy under load.

Every pattern here is paired with runnable artifacts, not pseudocode:

Atomic Lua scripts you can EVAL directly (rate limiter, sliding window,

lock acquire/release) — atomicity is the whole point, and Lua is how you get it.

redis-cli walkthroughs (scripts/*.sh) that you can paste line by line to

watch a pattern behave.

Dependency-free Python (examples/*.py) built on a tiny RESP client that

speaks the Redis wire protocol over a plain socket — no pip install required.

An annotated redis.conf that explains why each tuning knob matters, not

just what it is set to.

Who this is for

Backend and platform engineers who already run Redis (or are about to) and want

correct, copy-pasteable implementations of the patterns that are easy to get

subtly wrong: locks that release someone else's lock, rate limiters that leak

under concurrency, caches that stampede a cold key, and streams consumer groups

that lose messages on crash.

Prerequisites

Redis 6.2+ (7.x recommended). Streams require 5.0+, GETDEL requires 6.2+,

and the eviction notes assume the 7.x maxmemory policies. Where a feature

needs a newer server, the doc says so.

redis-cli on your PATH for the shell walkthroughs.
Python 3.10+ for the examples/ scripts. They use only the standard

library — socket, time, hashlib, uuid. There is nothing to install.

A Redis instance you can talk to. Everything defaults to 127.0.0.1:6379;

override with the REDIS_HOST / REDIS_PORT environment variables.

Hostnames such as cache01.example.com throughout the docs are placeholders.

Replace them with your own. No real infrastructure, addresses, or credentials

appear anywhere in this product.

How to run


# 1. Point at your Redis (defaults shown)
export REDIS_HOST=127.0.0.1
export REDIS_PORT=6379

# 2. Load the annotated config (optional, for a local test server)
redis-server config/redis.conf

# 3. Watch a pattern behave, line by line
bash scripts/cache_aside_demo.sh
bash scripts/leaderboard_demo.sh
bash scripts/streams_consumer_group.sh

# 4. Run an atomic Lua script straight from the file
redis-cli --eval lua/sliding_window.lua ratelimit:user:42 , "$(date +%s%3N)" 60000 5 "req-$RANDOM"

# 5. Run the dependency-free Python examples

*... continues with setup instructions, usage examples, and more.*

📄 Code Sample .py preview

examples/distributed_lock.py #!/usr/bin/env python3 """Distributed lock with a fencing token, as a Python context manager. Redis Patterns Library ====================== Wraps ``lua/acquire_lock.lua`` and ``lua/release_lock.lua`` so you can write:: with DistributedLock(client, "shipment:9001", ttl_ms=10_000) as lock: if lock.acquired: do_critical_work(fencing_token=lock.token) else: print("someone else holds it; back off") Why the two Lua scripts instead of plain SET NX / DEL: * acquire issues a strictly-increasing FENCING TOKEN atomically with taking the lock, so a resource can reject a stale holder (the GC-pause problem). * release deletes the key ONLY if it still carries our token, so we can never delete a lock that a later holder has taken over. Run the demo (needs a reachable Redis): python3 examples/distributed_lock.py Cluster note: the lock key and its fencing counter share a {hash tag} so both keys land on the same slot, which a multi-key Lua script requires. """ from __future__ import annotations import time import uuid from pathlib import Path from redis_client import RedisClient, RedisError LUA_DIR = Path(__file__).resolve().parent.parent / "lua" ACQUIRE_LUA = (LUA_DIR / "acquire_lock.lua").read_text() RELEASE_LUA = (LUA_DIR / "release_lock.lua").read_text() class DistributedLock: """A single-instance Redis lock with fencing token and safe release. Args: client: a connected RedisClient. resource: logical name of the thing being locked (e.g. "shipment:9001"). ttl_ms: auto-expiry safety net in milliseconds. Pick a value comfortably longer than the worst-case critical section, but short enough that a crashed holder frees the lock reasonably fast. retry: how many extra acquire attempts to make. retry_delay: seconds between attempts. # ... 99 more lines ...

Buy Now — $29 Back to Products