Day 94: Redis pub/sub, streams, distributed locks, rate limiting
Beyond caching: Redis's other data structures
Pub/sub lets publishers broadcast messages to channels that any number of subscribers can listen to — simple, but messages are fire-and-forget (a subscriber not currently connected simply misses them, unlike the durable queues in Days 95-97).
Redis Streams add durability and consumer groups on top of the pub/sub idea — messages are retained in a log, consumers can join a group to split work, and can acknowledge processing, closer to a lightweight message queue than plain pub/sub.
Distributed locks and Redlock
A distributed lock (using SET key value NX EX <ttl> — set only if not already set, with an expiry) lets multiple processes coordinate exclusive access to a resource across machines. Redlock is an algorithm for acquiring a lock safely across multiple independent Redis instances — and it's genuinely contested: critics (including a well-known critique from a distributed-systems researcher) argue Redlock's safety guarantees under real clock drift and process pauses are weaker than commonly assumed.
Why you now have the vocabulary to actually evaluate this debate
This isn't just trivia — it's Phase 7's lessons directly applied. Redlock's safety depends on assumptions about time and process pauses that Day 42 already told you can't be fully trusted in a distributed system. Understanding *why* the critique exists (not just that it exists) is what separates 'I've heard Redlock is controversial' from genuine judgment.
Rate limiting
A common pattern: INCR a counter key with a TTL window, reject requests once the counter exceeds a threshold — atomic, fast, and exactly the mechanism behind most simple API rate limiters (Phase 21 covers rate limiting design more broadly).
Key terms
- Redis Streams
- A durable, consumer-group-capable log structure, more queue-like than plain pub/sub.
- Redlock
- An algorithm for distributed locking across multiple Redis instances, with contested safety guarantees.
Why is Redlock's safety considered debatable by some distributed systems practitioners?
