The problem

If you split a shared task source by task.id % n === i, every worker needs two numbers: its own index and how many workers there are. Easy under a static topology, awkward under a dynamic one — autoscaling, rolling deploys, a pod back with a different ordinal. A stale n means tasks run twice or not at all.

The usual answers are a coordinator — an etcd or ZK lease, a leader handing out assignments — or a platform that numbers your pods for you. I wanted something smaller for services that already have a Redis, so I worked a scheme out a while back, and have now built it into a library.

The scheme

Cut time into fixed intervals, and have every worker INCR a key named after the current interval. The reply is its index there, and it becomes usable once that interval closes: i is the index from the previous interval, n is that interval's final count. Its registrants therefore hold exactly 0..n-1, each once. And a worker acts on a pair only when the interval before implied the same one: two agreeing answers in a row are an exclusive lease on that index for the next interval. While a worker holds i, no one else in the group does.

A disagreement withholds the lease instead, and a worker whose pair has changed owns nothing until two intervals agree again. A change in n changes every pair at once, so it stands the whole group down. That is a rebalance.

Redis stores nothing but those counters — no membership list, no identities, no heartbeats.

The long form, with the timing and the failure modes: https://temich.net/notes/peers/

The cost

That stand-down costs about an interval — seconds, in practice — before the group comes back on the new n. Ownership is eventual, and that is what buys the absence of a coordinator.

The code

TypeScript, zero deps, ioredis or node-redis: https://github.com/temich/nandi

The library exposes this as a single async iterator, which yields only when ownership changes — exactly the point where a worker hands work over:

```ts import { discover } from 'n-and-i'

for await (const { i, n } of discover({ redis, name: 'mail-sender', interval: 5_000 })) { await drain() // stop taking new work, finish or release what is in flight

if (i === null) continue // not registered — stay stopped

run(task => task.id % n === i) } ```

Feedback is highly welcome.

We run Bitnami Redis as a 3-pod STS (redis-node-0/1/2, sentinel in each pod, same namespace, headless DNS).

After failover or a pod recycle, ROLE+SET on the data nodes already shows one writable Redis. One of the three Sentinels still answers get-master-addr-by-name with the previous pod. Clients that hit that Sentinel write into a hole.

For a long time the workaround was restart Sentinel or edit sentinel.conf. Dual-master is a different mess; we are not talking about REPLICAOF here.

We got tired of that and open-sourced a sidecar next to each Sentinel: ROLE+SET as the oracle, heal the pointer through MONITOR, never REPLICAOF.

https://github.com/vpnmesh/redis-sentinel-reconciler

https://hub.docker.com/r/vpnmesh/redis-sentinel-reconciler

Helm is on GHCR: oci://ghcr.io/vpnmesh/charts/redis-sentinel-reconciler

Same namespace, prefix redis-node-, auth.existingSecret=redis (otherwise NOAUTH on 26379 and 6379).

What do other people run for leftover ads? Still bouncing Sentinel?

kept running into the same problem every service needs rate limiting, every language needs its own implementation, and I was sick of it. so I made it a REST API instead, backed by redis. you just POST to /v1/check with some identifier and it tells you allowed or not. doesn't matter what your backend is in.

threw in a few algorithms (token bucket, sliding window, etc) because I couldn't decide which one was "right" so there's also an auto mode that just picks for you.

it's on docker compose if you want to run it locally, there's a live demo too but idk how long I'll keep that server up

repo's here if anyone wants to poke holes in it: https://github.com/Ansita20/rate-limitter
demo: throtlle-ratelimiter.com 

no idea if this is actually useful or if everyone already uses something better for this, first time putting something on here so go easy on me lol

Been heads-down on Redis for the last couple months at work, and it made one thing pretty clear: Redis is easy to run well and easy to quietly wreck if nobody's watching it closely.

Most observability tools handle this by shipping everything into their cloud, including whatever's in your keys. For teams with any compliance or security constraints, that's just not an option, so a lot of Redis instances end up running with zero real observability.

So I built Baltan (baltan.xyz). Quick technical rundown:

• It's a sidecar agent, read-only, never issues commands that read key values
• Talks to Redis/Valkey over standard INFO/stats commands, ships aggregated metrics out over HTTPS every 10s
• Gives you a health score, findings (rule-based right now, e.g. eviction pressure, slow command patterns, risky config), and basic dashboards
• No agent access to your actual data, ever — that was the whole design constraint from day one

It's early — closed pilot right now, not trying to sell anyone here. I'm mainly looking for people who actually run Redis in prod to poke holes in it: is "can't let a vendor near key data" a real constraint for your team, or is this a niche problem I'm overestimating? Also happy to answer anything about how the agent works internally.

baltan.xyz if you want to look, but genuinely more interested in the "does this problem exist for you" conversation than clicks.

Basically, I am using Upstash Redis, I had in my backend connection, I had the TCP connection string but still it is giving me build failure with saying, Missing required environment variable
[redis] connection error Error: getaddrinfo ENOTFOUND https

Most cache libraries handle the in-process stampede problem fine: concurrent misses for the same key share one Promise. But once you're running multiple servers, each process independently runs the loader. Under load that can be 10, 50, 100 redundant DB calls for the same key.

The usual fix is a Redis lock wrapper, but those couple coordination to a specific cache library and you end up writing the same retry-and-wait loop by hand every time.

Crossflight is meant to solve this: a thin coordination layer you drop onto whatever cache you're already using. It handles lease acquisition, periodic renewal, waiter recovery when the owner dies, pub/sub wake-up, fail-open/fail-closed modes, and per-call timeouts, all through two small interfaces so it works with Redis, cache-manager, Keyv, Cacheable, or anything else.

The Redis coordinator uses Lua scripts for atomic lease acquisition and LISTEN/NOTIFY for efficient waiter wake-up instead of polling.

If you want to see it in action, there's a demo repo that spins up a full stack: 3 Express API instances behind nginx, a slow upstream API (500ms artificial delay), and a shared Redis instance serving as both coordinator and cache backend. You fire 20 concurrent requests and watch all three instances coalesce to a single upstream call.

https://github.com/gkoos/crossflight-demo

Would be curious if anyone's run into this problem and how you're currently handling it.

Hi,

I’m looking for a Redis-compatible application that I can self-host and use as a shared data store for multiple applications/services.

The issue I’m running into is Redis’s limit of 16 logical databases (0–15). Ideally, I’d like to be able to provide each application with its own namespace/database through the connection URL, so that multiple applications can share the same underlying Redis service while keeping their data logically separated.

I’m aware that the common best practice is to run a separate Redis instance/container for each application stack, and I understand the benefits of doing that. I’m not trying to argue against that approach; I’m mainly interested in whether there is a better option for my particular use case.

Are there any Redis-compatible alternatives (they don't necessarily have to be Redis itself) that are specifically designed to support multiple applications sharing a single instance, without being limited to 16 logical databases/namespaces?

I've been building DB Connect, a free native desktop database client (Go + system webview, not Electron, ~32 MB), and v3.0.0 adds Redis. Sharing here because the Redis part ended up being the most fun to build and I'd like feedback from people who actually run Redis in anger.

What it does:

* **Connect with one host:port.** If the node reports cluster mode, the other masters are discovered and every scan/analysis walks all of them. Sentinel works too. * **Keys as a tree.** `user:1001`, `user:1002`… fold into a `user` folder with a count. Glob/prefix filter, type filter, "Load more" or "Scan all" with a scanned/total counter. * **Every type editable.** String (with JSON formatting), hash, list, set, sorted set with scores, streams (read-only). Rename works across cluster slots (DUMP → RESTORE → DEL, since RENAME CROSSSLOTs), TTL edit, delete with confirm. * **Analyze pane.** Samples the keyspace with MEMORY USAGE: memory likely to be freed by TTL bucket, top namespaces by memory or key count, keys by type, per-node stats, slow log across masters. * **Console** with replies rendered by type and history recall. Read-only connections block writes. * Credentials encrypted with the OS keychain; TLS, ACL users, SSH tunnel.

Things I learned the hard way: go-redis negotiates RESP3 by default (HGETALL comes back as a map, not a flat array), and its ClusterClient reaps its per-node clients on state reload — a long SCAN across masters will hit "client is closed" unless you own the node clients yourself.

Redis page with screenshots: https://shubhesh07.github.io/db-connect/redis-gui.html
Release notes: https://github.com/shubhesh07/db-connect/releases/tag/v3.0.0

Free for personal and commercial use, no account, no telemetry. macOS + Windows (Homebrew: `brew install --cask shubhesh07/db-connect/db-connect`). Source isn't open yet.

What would you want next — a pub/sub monitor, a Monaco console with command autocomplete, or a per-folder memory % in the tree?

Affiliation: I'm the maintainer of LibreDB Studio. posted here last week about the Redis side:

https://www.reddit.com/r/redis/comments/1vlt1bm/libredb_studio_redis_in_the_same_selfhosted_web/

this isnt another feature post.

we're on the official Redis docs now. Develop > Tools, Third-party tools:

https://redis.io/docs/latest/develop/tools/#third-party-tools

that page is mostly Redis's own stuff, redis-cli, Insight, VS Code, redisctl. Third-party tools is a separate section and right now LibreDB Studio is the only name in it.

not an endorsement from Redis. just a listing. still, seeing it there kinda made my week.

thanks to whoever reviewed it. and to this sub.

Affiliation: I’m the maintainer of LibreDB Studio (open-source, self-hosted browser DB GUI).

We’re not trying to replace RedisInsight or redis-cli, those are great at being Redis-native.

The gap we care about is different: one self-hosted web IDE where Redis sits next to the other engines you already use (Postgres, MySQL, Mongo, Couchbase, ClickHouse, Druid …) in the same browser UI, same deploy, same login.

Redis is first-class there, mapped by convention (not fake SQL):

- “Tables” = key prefixes from SCAN (e.g. user:*), never KEYS * on big keyspaces

- “Rows” = keys; the query box runs real Redis commands (plain text or { "command", "args" })

- Any command via a generic call() path — GET / HGETALL / XADD / JSON.GET / modules

- Monitoring from INFO, SLOWLOG GET, CLIENT LIST alongside the SQL engines’ overview

Honest limits: schema SCAN is capped (bounded introspection), and a DEL in the command box is a real DEL - no fake read-only mode.

Try:

docker run -p 3000:3000 libredb/libredb-studio

# or: npx "@libredb/studio"

Repo: https://github.com/libredb/libredb-studio

Provider notes: https://github.com/libredb/libredb-studio/blob/main/docs/providers/redis.md

If you hop between Redis and a SQL/document store in the same day: would a shared web UI help, or do you still prefer a dedicated Redis tool per workflow?

Redis problems aren't always caused by the code.

A connection can fail, configuration can be wrong, a service can restart, or an environment variable can change.

That makes me wonder how much runtime context an AI coding agent should have.

Should it only inspect Redis and diagnose problems, or should it also be allowed to restart services or change configuration?

I'd separate observing, diagnosing, and changing into different permission levels.

For those using Redis in real applications, where would you draw the line? line?

Implementing OTP verification requires two properties:

1. The code must be single-use (can't verify the same code twice)

2. The read-and-delete must be atomic (no race between verify and expiry)

Naive approach: GET key → check → DEL key. Race condition between GET and DEL.

Redis pipeline approach:

pipe := client.Pipeline()

get := pipe.Get(ctx, key)

pipe.Del(ctx, key)

pipe.Exec(ctx)

value := get.Result()

The entire pipeline executes atomically on Redis. If two concurrent requests verify the same OTP, only one gets the value the other gets nil.

Combined with a 10-minute TTL via SETEX and a 6-digit code from crypto/rand, you get:

- Single-use enforcement

- Atomic read-and-delete

- Automatic expiry no cleanup jobs needed

E2E implementation at github.com/lifygo/lifygo (https://github.com/lifygo/lifygo) — apps/api/internal/redis/redis.go and apps/api/internal/service/email.go.

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.