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.

Give me the best Resources to build this project.

Also tell me which programming language will be best for this and why?

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