Redis

What we're doing: Write and read a string value, use SETNX to avoid overwriting an existing key, and INCR to update a counter without a race condition.

r.set("user:1001:name", "Priya Shah")
print(r.get("user:1001:name"))

r.set("page_views", 1)
r.incrby("page_views", 5)      # 1 from set, +5 here = 6
print(r.get("page_views"))

r.setnx("user:1001:name", "Someone Else")   # key exists — no-op
print(r.get("user:1001:name"))

r.append("user:1001:name", " (verified)")
print(r.get("user:1001:name"))

2

r.get returns the string exactly as stored — decode_responses=True on the client turns the raw bytes into a Python str.

7

setnx ("SET if Not eXists") only writes when the key is absent — since user:1001:name already exists, this call does nothing.

10

append adds to the end of the existing string value and creates the key if it was missing — it does not error.

Priya Shah
6
Priya Shah
Priya Shah (verified)

Why this works: set/get map directly onto Redis storing one value per key. incrby is atomic on the server — Redis, not your Python process, does the read-add-write, so two clients calling it concurrently never lose an update the way a plain get-then-set would. setnx makes "create if missing" a single round trip instead of a check-then-act race.

What we're doing: Build a small job queue: push work onto a list and pop it with a blocking read so a worker does not have to poll.

r.rpush("job_queue", "task:a", "task:b")

print(r.llen("job_queue"))            # 2
print(r.blpop("job_queue", timeout=1))   # ('job_queue', 'task:a')
print(r.lrange("job_queue", 0, -1))   # remaining: ['task:b']

1

rpush enqueues work at the tail — first task pushed is first to come out via lpop/blpop.

5

blpop blocks up to timeout seconds waiting for an element rather than returning None immediately on an empty queue — the standard pattern for a worker that should sleep, not poll.

2
('job_queue', 'task:a')
['task:b']

Why this works: rpush/lpop make the list behave as a FIFO queue: work goes in at the tail and comes out at the head in the order it arrived. blpop turns "wait for work" into one blocking call instead of a client-side sleep-and-retry loop, so a worker sits idle at zero CPU cost until something is pushed.

What we're doing: Tag a post with a set, find overlapping tags between two posts, then rank users on a sorted-set leaderboard.

r.sadd("tags:post42", "python", "redis", "backend")
r.sadd("tags:post7", "python", "frontend")

print(r.sinter("tags:post42", "tags:post7"))   # shared tags

r.zadd("leaderboard", {"alice": 100, "bob": 250, "carol": 175})
r.zincrby("leaderboard", 50, "alice")          # alice now 150

print(r.zrevrange("leaderboard", 0, 0, withscores=True))  # current leader
print(r.zrank("leaderboard", "carol"))                     # ascending rank

1

sadd builds the tag set for post 42 — order does not matter and re-adding "python" later would be a no-op.

6

zadd sets three members with scores in one call; zincrby then updates one member's score atomically without reading it first.

9

zrevrange(key, 0, 0, withscores=True) reads just the single highest-scoring member — the current leaderboard leader.

{'python'}
[('bob', 250.0)]
1

Why this works: sinter runs the set intersection on the server and returns only the result, rather than pulling both full sets into Python to compare — the same reason sunion/sdiff exist. zincrby is atomic for the same reason incr is: no read-modify-write gap for a concurrent update to land in, which matters for a shared leaderboard.

What we're doing: Store a user profile as a hash, read a subset of fields, increment a counter field, and remove one field.

r.hset("user:1001", mapping={
    "name": "Priya Shah", "email": "priya@example.com", "logins": 4,
})

print(r.hget("user:1001", "name"))
r.hincrby("user:1001", "logins", 1)
print(r.hget("user:1001", "logins"))
r.hdel("user:1001", "email")
print(r.hexists("user:1001", "email"))

1

A single hset with mapping= writes all three fields in one round trip, instead of three separate string keys.

6

hincrby treats the "logins" field as an integer and adds to it atomically, the same guarantee incr gives a top-level string key.

8

hdel removes just the email field — name and logins are untouched, and the key itself still exists.

Priya Shah
5
False

Why this works: A hash groups related fields under one key, so hgetall/hdel/hincrby operate on the whole object without needing to know every field's name up front, and without the client stitching together several separate GETs into one object.

What we're doing: Set a TTL two ways, read it back, remove it with persist, and check a millisecond TTL actually expires the key.

r.set("cache:homepage", "<html>...</html>", ex=60)
print(r.ttl("cache:homepage"))          # 60

print(r.persist("cache:homepage"))      # True: TTL removed
print(r.ttl("cache:homepage"))          # -1: exists, no TTL

r.set("short_lived", "x", px=50)        # 50ms TTL
time.sleep(0.1)
print(r.get("short_lived"))             # None: already expired
print(r.exists("short_lived"))          # 0

1

ex=60 sets the value and a 60-second TTL in the same round trip as set — the usual way to write a cache entry.

5

persist strips the TTL entirely; the key and its value are unaffected, but it will not auto-expire anymore.

9

After sleeping past the 50ms px= TTL, the key is gone — get returns None exactly as it would for a key that never existed.

60
True
-1
None
0

Why this works: Redis tracks each key's expiry internally and removes it lazily on access or via a background sweep — your code never has to check the time itself. ex=/px= on set() is the same expire call folded into the write so there is no window where the key exists without its intended TTL.

What we're doing: Decrement stock safely under concurrency using WATCH/MULTI/EXEC, retrying if another client changes the key first.

import redis

r.set("stock:sku9", 5)
with r.pipeline() as pipe:
    while True:
        try:
            pipe.watch("stock:sku9")
            current = int(pipe.get("stock:sku9"))
            pipe.multi()
            pipe.set("stock:sku9", current - 1)
            pipe.execute()
            break
        except redis.WatchError:
            continue   # someone else changed it first — recompute and retry

print(r.get("stock:sku9"))

4

watch tells Redis "abort my transaction if this key changes before I EXEC" — read happens after watch, so nothing is missed.

8

pipe.multi() switches the pipeline into queuing mode — subsequent commands are queued, not sent, until execute().

10

execute() sends MULTI + the queued commands + EXEC as one atomic block, but only if stock:sku9 has not changed since watch().

13

A WatchError means another client wrote to stock:sku9 first — the loop retries with a freshly read current value instead of overwriting blind.

4

Why this works: watch/multi/execute is optimistic concurrency control: instead of blocking other clients out with a lock, Redis lets everyone proceed and only refuses to commit if the watched key actually changed underneath you — cheaper than locking when conflicts are rare, at the cost of a retry loop when they are not.

What we're doing: Publish and receive one Pub/Sub message, then append two entries to a stream and read them back with a consumer group.

pubsub = r.pubsub()
pubsub.subscribe("notifications")
print(pubsub.get_message(timeout=1))   # subscribe confirmation, not a real message

r.publish("notifications", "order:1001 shipped")
print(pubsub.get_message(timeout=1))   # the actual message

msg_id = r.xadd("events:orders", {"order_id": "1001", "status": "created"})
r.xadd("events:orders", {"order_id": "1002", "status": "created"})
print(r.xlen("events:orders"))

r.xgroup_create("events:orders", "workers", id="0")
read = r.xreadgroup("workers", "consumer-1", {"events:orders": ">"}, count=1)
print(len(read[0][1]))   # entries delivered to consumer-1 in this read

3

The first get_message() after subscribe() is always the subscription confirmation itself, not application data — a common first-message surprise.

8

xadd returns an ID combining the millisecond timestamp and a sequence number, guaranteeing IDs are strictly increasing even for entries added in the same millisecond.

13

xreadgroup with ">" delivers only entries not yet claimed by any consumer in the "workers" group — a second consumer reading the same group would get the next unclaimed entry, not a repeat.

{'type': 'subscribe', 'pattern': None, 'channel': 'notifications', 'data': 1}
{'type': 'message', 'pattern': None, 'channel': 'notifications', 'data': 'order:1001 shipped'}
2
1

Why this works: Pub/Sub delivers only to whoever is subscribed at publish time and keeps nothing — fine for "notify anyone currently listening," wrong for anything that must not be missed. Streams persist every entry with a durable ID, so xrange/xreadgroup can always retrieve history a late-joining or restarted consumer would otherwise have missed under Pub/Sub.

What we're doing: Acquire a lock, prove a second acquire attempt is refused while it is held, then release it safely with the token-checking Lua script.

import uuid

token = str(uuid.uuid4())
acquired = r.set("lock:invoice:99", token, nx=True, px=5000)
print(acquired)                 # True — lock acquired

blocked = r.set("lock:invoice:99", "other-token", nx=True, px=5000)
print(blocked)                  # None — someone else already holds it

release_script = """
if redis.call("get", KEYS[1]) == ARGV[1] then
    return redis.call("del", KEYS[1])
else
    return 0
end
"""
release = r.register_script(release_script)
result = release(keys=["lock:invoice:99"], args=[token])
print(result)                   # 1 — released, token matched
print(r.get("lock:invoice:99")) # None — key is gone

3

nx=True makes this a "set only if absent" — the return value True confirms client A won the race and now holds the lock.

6

A second nx=True attempt on the same key while it exists returns None (falsy) — this is how another process learns it did NOT get the lock, without blocking.

17

The Lua script runs GET and DEL as one atomic server-side step — no other client can slip a write in between the check and the delete.

True
None
1
None

Why this works: nx=True turns "claim this resource" into a single atomic command instead of a check-then-set race. The release script closes the matching gap on the other end: without it, a compare done in Python (GET, compare, then DEL as two separate commands) has a window where another client could acquire the lock in between your GET and your DEL — and your DEL would then delete a lock that is no longer yours.

What we're doing: Implement cache-aside for a slow lookup and confirm the first call is a miss (does the real work) while the second is a hit (skips it).

def get_user_profile(user_id, db_lookup):
    cache_key = f"cache:user_profile:{user_id}"
    cached = r.get(cache_key)
    if cached is not None:
        return cached, "HIT"
    value = db_lookup(user_id)
    r.set(cache_key, value, ex=300)
    return value, "MISS"

def fake_db_lookup(user_id):
    return f"profile-data-for-{user_id}"

print(get_user_profile("1001", fake_db_lookup))
print(get_user_profile("1001", fake_db_lookup))   # same call, now cached

1

db_lookup is passed in rather than hardcoded so the same cache-aside shape works for a database query, an API call, or any other expensive function.

4

A cache hit returns immediately — fake_db_lookup (the 'slow' path) never runs a second time.

7

ex=300 caps how long a stale profile can be served after the underlying data changes — 5 minutes here, tuned to how fresh the data needs to be.

('profile-data-for-1001', 'MISS')
('profile-data-for-1001', 'HIT')

Why this works: The first call finds nothing under cache:user_profile:1001, so it pays the full db_lookup cost and populates the cache. The second call finds the cached value and returns immediately — the pattern's entire benefit is that a repeat lookup for the same key skips the expensive path, at the cost of possibly serving data up to `ex` seconds old.