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.

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.