Sharing redlock4j, a Java take on distributed locking, including multi-node consensus locking as described by the Redlock algorithm. It's plain Redis, so it runs anything RESP-compatible. No modules, no managed service. A simple distributed lock just implements the JDK Lock interface:

    // full multi-node Redlock quorum, or single node — same code
    Lock lock = redlockManager.createLock("orders:reindex");
    lock.lock();
    try {
        reindex();
    } finally {
        lock.unlock();
    }

Son interesting features

• RESP3 push notifications so one connection carries both commands and keyspace-notification pub/sub — waiters wake on lock release in single-digit ms instead of polling (Falls back to polling where CONFIG/keyspace events are locked down).
• Auto-detects native CAS/CAD (DELEX ... IFEQ, 8.4+) for safe release/extend, with a Lua GET==token then DEL fallback on older servers.
• Multi-node quorum acquire/release fans out in parallel (CompletableFuture), so 3 nodes cost ~max(RTT) instead of 3 × RTT.
• see the guide for more information

Benchmarks (mostly vibe-coded so take them with a grain of salt)

(Testcontainers, 3-node Redis 7 cluster, 50 ms work per critical section, 60 s measurement, vs Redisson)

Throughput (ops/s, higher is better):

p99 latency (ms, lower is better):

The RW-writer gap is the interesting one - Redisson's writer path seems to starve hard under reader load, redlock4j stays ~100 ms at p99.

Where it's still behind, honestly: plain 3-node DistributedLock throughput (0.81 vs Redisson's 18.24) and 3-node FairLock — both bottlenecked on the polling floor. Fixing that (a pub/sub-on-release wait strategy) is the next big lever.

This is a personal project, actively maintained, licensed under MIT, Java 8+, on Maven Central.

Genuinely after feedback on the direction and where the multi-node correctness cost is worth paying.

Hi r/redis,

I’m working on a small tool called pg2redis and I’d like to get feedback from Redis users.

The basic idea is to use Postgres logical replication/WAL as the source of cache updates. Applications write only to Postgres, and pg2redis reads committed changes from the WAL and applies configured Redis commands.

The main use case I imagine is cache invalidation. For example, when a product, customer, or order row changes in Postgres, the tool can delete or update the related Redis keys.

The problem I’m trying to avoid is the classic dual-write flow where application code saves to Postgres and then updates Redis. If the Postgres transaction commits but the Redis write fails because of a timeout, network issue, deploy, or crash, the cache can become stale or inconsistent.

The tool supports batching by size/time and automatic retries.

This is still a work in progress and not open source at the moment. I’m mainly trying to validate whether the approach makes sense from a Redis point of view.

For people using Redis as a cache in front of Postgres:

Do you think WAL-driven cache invalidation is useful?

Would you trust this kind of approach for production cache updates?

Thanks, I’d appreciate any feedback.

alik @ pgwalk

Hi,

Would this be a correct use of redis and redis stream ?

1. API stores model in redis.

2. API sends signals to a service via a redis stream.

3. Service gets model from redis then do something and updates it in redis.

4. Service sends signals to API via another redis stream.

5. API gets model from redis and send update to UI.

i recentlly came to knmow that valkey and i heard that its open source and its llike fork of redfis underBSD-3 licence so is it like completly free or are there some charges as the load increase

The naive approach — one key per user (user:123:status) — breaks down fast when a user has multiple tabs/devices open. Tab A closes, sets status to offline, but Tab B is still active. Now you've got a false "offline" signal.

Better pattern: track connections, not users. Use a Redis Set per user, like user:123:connections, and add a unique connection ID (socket ID) on each tab/device connect, then remove it on disconnect. User is "online" as long as that set is non-empty — check with SCARD.

For reliability, pair each connection with a heartbeat using SETEX (short TTL, e.g. 30s), refreshed periodically from the client. If a tab crashes without firing a clean disconnect event, the heartbeat key just expires naturally — no zombie "online" state left behind.

This combo (Set for multi-tab tracking + TTL heartbeat for crash recovery) keeps presence accurate without extra cron jobs or manual cleanup.

Anyone doing this differently? Curious how others handle the multi-device edge cases.

Hey folks,

I put together a small Redis RESP protocol cheat sheet while working on some lower-level Redis tooling, and I’m sharing it in case others find it useful.

It’s aimed more at implementation work than day-to-day Redis usage. It covers things like command shapes, RESP2/RESP3 reply formats, null and timeout cases, blocking behavior, Pub/Sub push messages, transactions, streams, and common server errors.

I put it together quickly with AI to have a practical reference in one place, so it’s definitely incomplete and likely has a few gaps. Contributions and corrections are very welcome, especially for missing commands, incorrect reply shapes, and edge cases.

It currently covers 79 commands, and I’ll keep expanding it over time if people find it useful. PRs with additions or fixes are very welcome.

It might be useful if you’re building or testing Redis clients, proxies, protocol test suites, Redis-compatible servers, or RESP parsers/serializers.

GitHub URL: https://github.com/martinkolarov/redis-protocol-cheatsheet
Hosted version URL: https://martinkolarov.github.io/redis-protocol-cheatsheet/

Hey everyone, looking for some architectural advice on handling Redis failovers gracefully under high traffic.

Our Setup:

Node.js backend using ioredis

Redis Sentinel (Bitnami Helm Chart) running on AWS EKS (Karpenter for node provisioning)

1 Master, 2 Replicas

What we've done so far: We found that the default Bitnami preStop hook uses CLIENT PAUSE during pod termination, which freezes our app for ~20s and causes massive TimeoutErrors.

We overwrote the preStop script to remove CLIENT PAUSE and instead trigger a SENTINEL FAILOVER immediately, followed by cleanly severing the TCP connections. On the Node.js side, we use ioredis with maxRetriesPerRequest: null and enableOfflineQueue: true.

The Result: When a node is drained, ioredis catches the dropped connection, buffers all incoming commands in memory, asks Sentinel for the new master, and flushes the queue once connected. The failover usually takes about 2 to 5 seconds. To the end user, this just looks like a slightly slower API request. No 500 errors.

My Questions for the community: While this works perfectly in testing, I know we can't guarantee a strict 2-second failover in production.

Under heavy traffic and large datasets, Sentinel elections and DNS propagation could easily push this delay to 5-10 or 15 seconds or more.

If the delay extends to 10 seconds under massive traffic, our Node.js ioredis in-memory buffer will explode in size, potentially causing OOM crashes on the application side, or massive latency spikes when it finally flushes thousands of queued commands to the new master at once.

How do you handle this at scale?

Do you just accept the 5-10 second latency spike during a failover?

Is migrating to a managed service like AWS ElastiCache the only way to avoid this completely?

Would love to hear how folks are handling Redis HA edge cases at scale!

I built Khazad, a Python semantic cache for LLM API calls based on Redis Vector Sets with 3 dependencies.

It works by intercepting outgoing LLM HTTP requests at the httpx transport layer, no SDK wrappers, no proxy, zero app code changes (2 lines).

Each (provider, model) pair gets its own vector set. On every intercepted request I embed the

conversation, run a VSIM similarity search, and if the top match clears a

threshold I replay the cached response, otherwise the call goes upstream and

the new (vector, response) pair is added with VADD. TTL support handles expiry

for privacy and freshness.

Requires Redis 8 for Vector Sets. MIT licensed. Curious if anyone here has

pushed Vector Sets in some production and at what scale.

GitHub: https://github.com/GuglielmoCerri/khazad

I kept seeing the same failure mode in Redis-backed systems: Redis starts as a cache, but over time parts of the app quietly begin depending on cached data as if it were the source of truth.

I've made a small free software. Could you check it?

https://github.com/balyakin/cache-proof

Most people assume Redis is fast because of some complex multi-threaded magic. Turns out it's the opposite — it runs on a single thread and still beats most databases. The reason comes down to how it handles I/O at the OS level and why memory access patterns matter more than thread count. Made a short animated breakdown of the internals if anyone's curious.

hey i have completed my second year engineering cs major and having my summer break my tech stack is nextjs typescript i want to learn redis how do i start what project should i built that will do the thing please guide me

How can i migrate from 8.0.1 to 7.0.1
I downgrade one slave node to 7.0.1.
then restart it, waiting for the node replication.
But it became failed. there is a log "unknown extension type 3 or 4" in the redis log.

I think it is caused the migration failure.
So how can i resolve the problem.
Have anyone can help me?

While building a notification platform I needed a way to recover messages when workers died mid-processing.

My current approach:

- XPENDING
- XCLAIM
- Idempotency keys
- DLQ after max retries

Curious what patterns others use.

Architecture:
API
↓
Redis Streams
↓
Consumer Groups
↓
Enrichment Workers
↓
Decision Engine
↓
Push Notification Workers
↓
Firebase Cloud Messaging (FCM)

Happy to share implementation details if useful.

Redis is often treated as a simple cache, but its consistency model matters when you use it for more than that. This post breaks down where Redis sits on the consistency spectrum and how to think about its guarantees when paired with a primary database.

I cover the difference between strong consistency (ACID databases) and eventual consistency (Redis replication), plus when to use each. There is a section on read/write quorum patterns that explains how distributed systems handle failover without losing data. The diagrams make it easier to explain to teammates who are not deep into distributed systems.

If you are using Redis for session storage, caching, or as a primary data store, this will help you reason about its behavior under network partitions.

Hi Everyone!

We're launching Code BEAM Europe 2026 on 21-22 October in Haarlem, NL (and virtually). It is a 2-day technical conference for engineers and developers working with Erlang, Elixir, Gleam, and the BEAM ecosystem. Speakers will be announced soon. You will be able to check it on our website: https://codebeameurope.com

The Early Bird ticket sales start on 16 June at 12:00 PM. If you plan to attend, the best way to get the lowest price is to join our waiting list now - https://codebeameurope.com/#newsletter

By joining the list, you'll get two main benefits:

• You get an email notice 24h before the sale opens, and again at the sale's grand opening.
• You get early access to a small number of Super Early Bird tickets. These tickets are limited, so they will be given to those who buy them first.

We can't wait to meet you! 

Hey evryone,

I am in a project built with sb microservices and I'm trying to understand how redis is actually implemented and wired together in this setup. I feel like I've found pieces, but I'm struggling to connect them conceptually.

How do I make sense on these concepts: RedisConfigClass, spring-boot-starter-data-redis, azure redis cache, yml or properties file i believe also come but it doesn't seem to be in the same module.

What nonsense! I cannot download redis insight without giving all my data?

Do they even want people to use it?

Edit: Thanks all!

Redis 8.8 is out and ready to mess with. The big addition is a new data structure—the array. It's pretty much what you think it is—an index-addressable collection of strings. Like a list but with random access because, well, it's an array. Accessing elements is a lot faster than a list. And it's compacted so no wasted space.

The other interesting bit is a built-in rate limiter. Rate limiting is one of those things that everyone uses Redis for. But, you gotta write code to make one work. Sometimes Lua code. Now, it's built in.

A couple of things that I'm personally rather excited to see:

• More stream support: We added the XNACK command as the evil opposite of the XACK command. Now a stream consumer can explicitly say they *didn't* handle the message instead of leaving it pending.
• Hash field notifications: Keyspace notifications, but for fields in a hash. Now you can know what changed beyond the entire hash.

I haven't had a chance to use many of these yet—been focused on AI like the rest of the planet—but I know u/antirez added ARGREP to search the strings of an array for ones matching a pattern. Which sounds quite interesting.

It also suggests that we should add an SGREP, an LGREP, and maybe even grep commands for keys and fields in a hash.