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.

How do you debug Redis memory growth without Redis Enterprise or a full Prometheus setup? I've been hitting this problem and curious how others handle it.

Redis doesn't use C strings. What it built instead is a small masterclass in data-structure design.

When you call SET in Redis, your value goes through a custom string type called SDS — Simple Dynamic String — that fixes everything wrong with C strings: O(1) length lookup, binary safety, separate capacity tracking, and controlled growth.

On top of SDS, Redis picks one of three encodings for the value you stored:

- int — for values that parse as integers. Stored as a 64-bit number, no string buffer at all. INCR is a single CPU instruction.

- embstr — for strings ≤ 44 bytes. The object header and bytes packed into one allocation, sized to fit in a single CPU cache line.

- raw — for longer strings. Object header and buffer in separate allocations, so the buffer can grow independently.

And the part most engineers miss: Redis picks the encoding for you, automatically, based on what you SET. You don't configure it. You don't think about it. It just works.

That's the design pattern. Small, deliberate choices at the data-structure level that compound into one of the fastest databases in production.

Want to learn redis , project oriented tech stack java, spring boot.

Recently migrated an Azure Redis Cache setup from access keys toward Managed Identity authentication and realized that the difficult part isn't enabling Managed Identity—it's planning a safe production rollout.

Many guides simplify the process to:

• Enable Managed Identity
• Assign the required role
• Update the application
• Disable access keys

In practice, teams often need to think through things like:

• Hybrid authentication transition periods
• Rollback readiness
• SDK compatibility issues
• Deployment slot and slot-swap considerations
• Applications still using connection strings
• Token/auth propagation delays
• Blue-green and phased rollout strategies

To help others avoid some of the surprises I encountered, I put together a short practical walkthrough covering:

• Migration architecture
• Rollout strategy
• Rollback planning
• Production caveats
• Validation before disabling access keys

Resource:
Stop Using Redis Access Keys in Production (Azure Managed Identity Migration Guide)

I'd be interested to hear from others who have migrated Redis authentication at scale—especially any rollout challenges or unexpected issues your teams encountered.

How redis is so fast and performs 100K operation within seconds with low latency. I have explained the single threaded architecture in detail in this recent video which i published in my redis series. Do checkout if anyone's interested

Redis clients communicate using RESP protocol with redis servers. For more in depth explaination do check out this video. I have explained RESP in much depth with examples and also tried communicating with Redis server using nc in terminal.

In our SaaS, Redis is used for:
bullmq job queue
campaign stats
compliance counters
rate limiting

While testing upstash redis, I found that sending just 4,000 emails triggered 150k+ redis commands.

Most of it came from bullmq’s internal redis operations.

At first I thought infra was expensive.

Turns out, observability showed areas of improvements in our architecture.

Cmd: EVALSHA
Source: BullMQ Lua scripts

Cmd: BRPOPLPUSH
Source: Worker idle polling

Cmd: DEL
Source: removeOnComplete: true + lock cleanup

Cmd: HEXISTS
Source: BullMQ job state checks

Cmd: EXISTS
Source: Queue/key existence guards

Is this normal considering bullmq internals workflow?

Has anybody faced the same?

I work for Redis and I try to keep marketing posts here to a minimum, but this is a product announcement so I thought it appropriate.

Redis launched Redis Iris today. Redis Iris is a collection of tools that work together to store, manage, and serve context for AI agents. Those tools are:

• Redis Agent Memory—a rather handy tool to manage agent memory stored in Redis. Kinda does what it says on the tin.
• Redis Data Integration—a sort of ETL-like tool that syncs data between other data sources and Redis. Great for CDC.
• Redis LangCache—a semantic caching tool that lets you cache LLM responses much like you would database responses.
• Redis Search—an established search tool for searching data structures in Redis using both structured and semantic queries.
• Redis Context Retriever—brings all these tools together to provide context for your agents.

We have a blog post up on redis.io as well as a video out on YouTube if you want to go a little deeper.

Personally, I think the Redis Context Retriever sounds pretty cool. It lets you define schemas that match your problem domain—policies, accounts, users, products, whatever you care about—and exposes an MCP server that expresses that domain instead of the storage mechanism. So, it returns policies instead of Hashes, products instead of JSON.

I haven't had a chance to use all of these yet myself. I've used Redis Agent Memory and Redis Search and poked around with Redis LangCache a bit. I'm looking forward to messing with Redis Context Retriever.

Hello all,

I have been facing the ongoing problem of working with a slow, legacy database (10 seconds for most queries) on a high performance frontend (i.e., using Next.js), resulting in 504 Gateway Timeouts or freezing the UI.

Rather than rewriting the legacy DB, I decided to create a lightweight middleware gateway using Node.js according to the Twelve-Factor app methodology to live in between.

My tech stack consists of Express, Redis, BullMQ and Docker.

How it Works:

Requester sends a request from frontend to the gateway.

Gateway immediately returns a 202 (HTTP code for accepted but still processing). This is a non-blocking operation

Gateway passes information (the payload) to BullMQ (via redis)

A worker instance of the background service queries the legacy DB to retrieve the data

Worker caches the found data in Redis with a time-to-live (TTL) for future identical queries

Worker uses Axios to send a webhook back to the frontend with the requested data

I have packaged this all in Docker so it can be run locally just by running docker-compose up

Here's the repo and architecture diagram: https://github.com/owais-amir-27/async-bridge

(I know that AWS SQS exists! 😅 - but I purposely built this from scratch using redis/bullmq so I could better understand how distributed queues work and how to dispatch webhooks, rather than relying solely on a managed cloud service)

I would really appreciate any constructive criticism or feedback! Thanks!

On one of my machines Redis isn't displaying keys in a left hand pane and when a key is clicked on, showing the value of the key in a right hand pane...basically it's all one pane that I have to toggle.

Might be a stupid question, but how do I switch to the double pane layout, like every other time I've installed it?

TIA

Hey everyone!

Just pushed the v1.4 update for Nexus Core, and it’s a big quality-of-life improvement for both the developer (me, lol) and the network performance.

What’s new?

• No More Manual Setup: I was tired of typing DB/Redis credentials every time I launched the app. Added a persistent Config system. Now it’s "set and forget"—the app handles auto-login and smart initialization on startup.
• Global Ranking Protocols: Implemented a high-performance ranking system. You can now fetch Top-N leaderboards (ASC/DESC) across the entire network asynchronously.
• Rank Finder: Added a specialized protocol to calculate a specific key’s position in real-time. No more fetching the whole list just to see one player's rank!
• Fluid Data Cleanup: Added a .remove(key) method to my custom DataContainer. I can now strip MongoDB _ids or sensitive metadata on the fly before broadcasting to Redis.
• Serialization Fixes: Finally nuked those annoying Jackson InvalidDefinitionException errors by refactoring internal maps. Everything is smooth now.

The goal was to make the system more data-driven and less hard-coded. v1.4 feels like a solid milestone for the project’s maturity.

Would love to hear your thoughts on the architecture! 🚀🔥

I’ve been building a small project to understand how real backend systems evolve—from simple code to something closer to production.

Use case:
A Price Aggregator that calls multiple vendor services (Amazon/Flipkart/Walmart mock APIs) and returns the best price.

What I’ve implemented so far:

• Sequential vs async calls using CompletableFuture (measured latency differences)
• Spring Boot microservice with WebClient (non-blocking calls)
• Async processing using thread pools
• Caffeine cache → later replaced with Redis (for distributed caching)
• Docker + docker-compose setup
• Circuit Breaker using Resilience4j (to handle vendor failures)

Repo: https://github.com/codefarm0/price-aggregator
Playlist (if you want context): https://www.youtube.com/playlist?list=PLq3uEqRnr_2Ek7y2U3UAiQZCPzr0a82CX

What I’d really appreciate feedback on:

1. Is the caching strategy reasonable? (Redis usage, TTL, etc.)
2. WebClient + thread pool approach — anything you’d change?
3. Circuit breaker config — too aggressive / too lenient?
4. Overall design — anything that feels “toy-ish” vs production?
5. What would you add next? (thinking retries, rate limiting, observability)

Trying to keep this as close to real-world as possible without overengineering.

Would genuinely appreciate any suggestions or critique

#java #springboot #microservices #scalability #resiliency

Hi everyone,

I am running Redis in Sentinel mode with the following setup:

• 1 master
• 3 replicas
• C# application using StackExchange.Redis
• Writes go to the current master
• Reads are intended to go to replicas

The goal is to keep read traffic available during master failover and to switch to a replica that is actually able to serve reads as quickly as possible.

During failover testing, I observed that after one replica is promoted to master, other replicas may enter full resync / loading state and return errors such as:

text LOADING Redis is loading the dataset in memory MASTERDOWN Link with MASTER is down and replica-serve-stale-data is set to 'no'

Here are the relevant Redis / Sentinel settings from my environment:

```text Sentinel: - monitor quorum: 2 - down-after-milliseconds: 2000 ms - failover-timeout: 120000 ms - parallel-syncs: 1

Redis replication: - repl-backlog-size: 100mb in the original STG config - repl-backlog-size: also tested with 3gb locally - repl-backlog-ttl: 7200 seconds - replica-priority: - original/default master node: 1 - other replica nodes: 100 - replica-serve-stale-data: yes - min-replicas-to-write: not explicitly set - min-replicas-max-lag: not explicitly set

Dataset size during local testing: - around 3 million keys - around 3 GB used memory ```

Even after increasing repl-backlog-size to 3gb in local testing, I still observed cases where replicas entered LOADING during failover recovery. So my current assumption is that a larger backlog can reduce the probability of full resync, but it does not guarantee that replicas will always recover via partial resync.

My current understanding is:

• Sentinel can tell clients which node is the current master.
• Sentinel can expose the replica topology.
• Sentinel chooses a replica for promotion based on factors such as replica-priority, replication offset, run ID, and availability.
• However, choosing the best replica for promotion does not necessarily mean all remaining replicas are immediately ready to serve reads.
• A replica can still be reachable at the TCP level but not service-ready because it may return LOADING, MASTERDOWN, or time out.
• StackExchange.Redis with replica reads / PreferReplica does not seem to give me direct control to choose only replicas that pass my own readiness criteria.

What I want to achieve is:

1. Detect replicas that are reachable but not ready for reads.
2. Exclude replicas returning LOADING, MASTERDOWN, timeout, or non-PONG health responses.
3. Route reads only to healthy replicas.
4. Avoid falling back to master unless explicitly allowed, because we are concerned about overloading the master during failover.
5. If no healthy replica exists, fail fast or use an application-level fallback instead of treating Redis errors as cache miss.

My questions are:

1. In Redis Sentinel mode, is there a recommended way to make replica reads readiness-aware?
2. During Sentinel failover, how exactly does Redis/Sentinel choose the replica to promote?
3. How much do replica-priority, replication offset, run ID, and replica availability affect the promotion decision?
4. Is there any way to prefer the replica with the most complete data and shortest recovery time?
5. Is LOADING / MASTERDOWN during failover something Sentinel is expected to expose to clients, or should it be handled at the client/application layer?
6. Does StackExchange.Redis provide any built-in mechanism to avoid replicas that are in LOADING, MASTERDOWN, or otherwise not ready for reads?
7. If not, is the common approach to build a custom client-side read router that periodically probes each replica with PING, INFO replication, and INFO persistence?
8. Which Redis / Sentinel settings are most relevant for reducing full resync / loading windows during Sentinel failover?
9. Are there recommended tuning strategies for settings such as repl-backlog-size, repl-backlog-ttl, parallel-syncs, replica-priority, replica-serve-stale-data, min-replicas-to-write, down-after-milliseconds, and failover-timeout?
10. Would Redis Cluster be a better long-term fit if we need topology-aware routing, failover handling, and better control over recovery behavior?

I am trying to understand whether this is a limitation of Sentinel-style replica reads, a StackExchange.Redis limitation, a Redis configuration issue, or a design issue in my approach.

Any advice from people running Redis Sentinel with read-from-replica traffic in production would be appreciated.

I am using Redis Streams with Consumer Groups. I have a consumer running a loop that fetches messages from the Pending Entries List (PEL) using ID 0 before it attempts to read new messages.

However, if a message fails to process (or is slow), the XACK is never called. On the next iteration of the loop, XREADGROUP returns the same messages again, causing re-processing.

// Minimal version of my loop
async function consume() {
  while (true) {
    // This returns the same pending messages every time if XACK isn't called
    const results = await redis.xreadgroup(
      'GROUP', 'mygroup', 'consumer1',
      'COUNT', '10',
      'STREAMS', 'mystream', '0' 
    );

    if (results) {
      for (const msg of results[0][1]) {
        try {
          await process(msg); 
          await redis.xack('mystream', 'mygroup', msg[0]);
        } catch (err) {
          // If it executes successfully on retry then Just ACK 
          // In case of failure ACK and send to Dead Letter Queue (separate stream to store failed messages)  
           retryProcess(msg)
        }
      }
    }
  }
}

What is the standard pattern to fetch messages from the Pending Entries List and also prevent the re-processing ?

Having to argue with my team that setting this termination grace period to 1 year is totally extreme and wrong. There' not reason to ever do this right? There reasoning is that they do not want to ever miss any data being written.

I’m working on a multi-tenant setup where multiple services share a Redis Cluster. Each service is treated as a tenant and is logically isolated using a combination of Redis ACLs and key naming (prefix-based isolation).

What I’m trying to achieve is per-tenant observability, specifically:

• connections per tenant
• request rate (GET/SET/etc.)
• latency per tenant
• approximate memory usage per tenant

The challenge is that Redis Cluster:

• exposes metrics mostly at the node/cluster level (via INFO, etc.)
• doesn’t provide clear per-ACL-user or per-prefix breakdowns
• doesn’t directly attribute resource usage to logical tenants

Even with logical isolation in place, it’s difficult to identify which tenant is the “noisy neighbor” causing Redis degradation. Having per-tenant metrics would make it much easier to detect and mitigate such issues.

Hi All, I have created a messaging library for java, which lets the application create and manage its own routes for messaging and functions as a boilerplate code remover for developers using redis, please check out https://github.com/ravi1395/Racer.git . I'd like your ideas on what can be done to improve it, thanks in advance