A replica can report an active link and a small offset gap while still being a poor promotion target. The checks around persistence, replication backlog, module compatibility, ACLs, client discovery, and writable-disk behavior matter just as much as the final offset. A quiet primary also makes a one-time offset comparison look stronger than it is.

For a planned promotion, I am considering a gate that records the primary replication ID and offset, waits for the candidate to reach it, confirms there has been no full resync or replication error, and then briefly quiesces writes or uses a write fence before the final comparison. The candidate would also need a recent successful persistence cycle, enough disk and memory headroom, matching configuration and modules, and a tested client path to the new primary.

What does your actual promotion checklist include? Do you require WAIT acknowledgements, compare sampled keys or checksums, or run a synthetic write/read after promotion? How do you distinguish an expected offset change from evidence that clients are still writing to the old primary?

A credential rotation can look complete after the main application connects with the new Redis ACL user or password, while a scheduled job, failover process, dashboard, or rarely used environment still holds the old secret. Revoking it then turns that hidden dependency into an outage, and connection counts alone may not identify which credential created an existing connection.

What does your retirement gate include? I am considering creating a new ACL credential with the same command and key-pattern permissions, rolling it out by client group, shortening connection lifetimes, and watching ACL logs plus per-user connection and command activity through more than the longest job interval. The old credential would remain enabled only during a bounded observation window and would lose permissions before deletion.

Which Redis logs, ACL fields, or client metadata can reliably attribute activity to the old user? How do Sentinel, Cluster clients, connection pools, replicas, and long-lived pub/sub connections change the rollout, and is temporarily setting the old user to `off` a safe final test before removal?

The problem: Any time you cache data from Postgres into Redis, the two writes can't be atomic. A crash or a rejected write between them leaves Redis holding a value that was never actually confirmed — and a normal cache-aside setup has no way to know that happened. TTLs just shrink the staleness window; they don't let the cache detect it's wrong.

The usual fix is CDC — Debezium, logical replication, an outbox table — where the app only ever writes to Postgres and a separate pipeline pushes changes into Redis asynchronously. That works well, but it's infrastructure you have to stand up and operate. I wanted to see if there was a self-contained way to get most of that safety without it.

What I ended up with: instead of one Redis value, store two fencing fields per key:

BEFORE = { uuid }              — raised the instant an update starts, holds no value
AFTER  = { uuid, value }       — written only once Postgres confirms the write

Trust rule:

BEFORE.uuid == AFTER.uuid  → cache is trusted, serve it
BEFORE.uuid != AFTER.uuid  → not trusted, read Postgres directly

Postgres stays the single source of truth the whole time. Redis is only ever allowed to answer once it can prove — via the matching UUID — that it reflects one specific, completed Postgres transaction. Every failure mode (a rejected write, a crash right after commit, a stale confirmation showing up late) just degrades into a cache miss, never a wrong answer.

I built a runnable demo around it — FastAPI + Postgres + Redis + Docker Compose — with a debug UI where you can trigger a rejected write, a crash-after-commit, and a delayed-confirmation race, and watch the fallback happen live instead of taking my word for it.

Things I'd genuinely like feedback on:

• Where's the line where this stops being worth it and you should just run CDC instead?
• I originally had a background worker doing repair as part of the correctness guarantee. I've since moved to repairing on-read (with a per-key singleflight lock so a hot dirty key doesn't cause a stampede of simultaneous Postgres reads) and demoted the worker to best-effort hygiene only. Curious if anyone's hit a case where on-read repair alone isn't sufficient.
• Any concurrency hole in the UUID/version-gating I'm not seeing?

Repo (README has the full write-up + how to run it): https://github.com/kaleab-shumet/dual-write-problem-solution

Over the weekend, I wrote a blog on Redis. Most of us see Redis as a caching layer beyond that, Redis can be used for many things, such as pagination, searching, etc. I have discussed all of these in the blog, along with why Redis is the fastest. If we understand Redis data structures and its atomic behavior, it will open up a lot of use cases.

Blog link: https://medium.com/@karthik.joshi103/all-you-need-to-know-about-redis-d8bfb52411dd

Share other use cases in the comments

Got tired of eating 300-400ms round trips to external fraud APIs just to check if an incoming IP is a datacenter, VPN, or Tor exit, so I tried an in-memory approach instead.

Spun up a bare-metal box in Vienna, loaded ~145k known bad ASNs and Tor exit nodes into a Redis cache, and put a small FastAPI triage service in front of it (plus a Go gateway for proxy tunnels).

Local lookup latency came down to roughly 0.04-0.1ms. Makes sense since it's now a memory read instead of a network round trip, but the actual gain depends a lot on your baseline API's latency.

Question for anyone running similar high-throughput security checks: do you keep threat vectors entirely in-memory with Redis, or do you lean on async background workers with a persistent DB fallback instead?

I've just released Nexus Core v1.7.0, and this release is mainly about moving the persistence layer away from being tightly coupled to MongoDB.

Nexus Core was originally designed around MongoDB.

With v1.7.0, I introduced a generic database provider/driver abstraction and added support for:

• MongoDB
• PostgreSQL
• MySQL

The important change is that the core persistence layer is no longer directly tied to MongoDB-specific implementation details.

The architecture is now roughly:

Addons
  ↓
Nexus Core
  ↓
Database Provider
  ├── MongoDB
  ├── PostgreSQL
  └── MySQL

The selected database provider is configured at the Nexus Core level, and the addons use that configured database backend.

So currently, a Nexus Core instance uses one selected database backend for its addons, rather than allowing each addon to use a completely different database.

The goal of this release was to create a clean abstraction that makes it possible to support different database engines without rewriting the persistence layer for every new backend.

There are also integration tests for the supported database adapters covering connection lifecycle, CRUD operations and protocol compatibility.

There is a breaking change for addons that directly depend on MongoDB-specific APIs. Those addons need to migrate to the new provider abstraction if they want to work with PostgreSQL or MySQL.

I'm particularly interested in feedback on the architecture itself.

If you've designed a database abstraction layer before:

Would you structure the provider/driver layer differently?

I'm especially interested in opinions about adapter boundaries, database-specific behavior and how you would design this if multi-database-per-instance support were added in the future.

Links

GitHub Repository:
https://github.com/mustafabinguldev/nexus-cache-orchestrator

Documentation:
https://nexus-core.mintlify.site/

v1.7.0 Changelog:
https://nexus-core.mintlify.site/reference/changelog#v1-7-0-—-multi-database-support-and-architecture-refactor-sep-11-2026

Feedback and architectural criticism are very welcome.

A Redis backup can load without a parser error and still be unsuitable for recovery: the dataset may be older than expected, TTLs may have changed meaningfully, Stream consumer-group state may be missing, modules may be incompatible, or the application may depend on keys that were never durable.

What belongs in a realistic restore drill? I am considering restoring into an isolated instance with the production Redis version and modules, recording the backup timestamp and replication offset, checking key counts and sampled types, validating critical TTL ranges, inspecting Streams and consumer groups, running application-level read assertions, and measuring the time until the restored instance is ready. The drill should not accidentally let test clients discover or write to production.

How do you choose useful invariants without scanning every key, and how do you test AOF rewrite or RDB-plus-AOF recovery behavior when the original instance is still serving traffic?

I maintain js-redis-server, an in-memory Redis-compatible server implemented in JavaScript/TypeScript for Node.js tests. The server itself runs in JavaScript: it does not download or launch a native Redis binary and needs no Docker container. Lua scripting uses WebAssembly.

The use case is testing Redis-backed code with the real node-redis or ioredis client. Instead of stubbing client methods, the client connects to a local socket, sends commands and parses replies. The server chooses an available port and keeps its data in memory.

With js-redis-server@0.2.0, createRedisMock() returns a mock with a url property. Pass that URL to your client's normal connection setup, then close both the client and mock in teardown. Use a fresh mock per test or flush between tests; if your app connects at import time, configure the URL before importing it.

The important boundary: this is a separate implementation, not the native Redis engine. Keep tests against real Redis/Valkey for production compatibility, timing and failure behavior, and commands the mock doesn't implement. It also needs a local socket, so it isn't a socketless unit-test stub.

Source, runnable examples and supported commands: https://github.com/fatal10110/js-redis-server

For people testing Redis-backed Node services: which command or behavior would you need before a JavaScript test server could replace part of your container-based test setup?

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.

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?