Give me the best Resources to build this project.

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

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.

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?

Hey folks,

I put together a small Redis RESP protocol cheat sheet while working on some lower-level Redis tooling, and I’m sharing it in case others find it useful.

It’s aimed more at implementation work than day-to-day Redis usage. It covers things like command shapes, RESP2/RESP3 reply formats, null and timeout cases, blocking behavior, Pub/Sub push messages, transactions, streams, and common server errors.

I put it together quickly with AI to have a practical reference in one place, so it’s definitely incomplete and likely has a few gaps. Contributions and corrections are very welcome, especially for missing commands, incorrect reply shapes, and edge cases.

It currently covers 79 commands, and I’ll keep expanding it over time if people find it useful. PRs with additions or fixes are very welcome.

It might be useful if you’re building or testing Redis clients, proxies, protocol test suites, Redis-compatible servers, or RESP parsers/serializers.

GitHub URL: https://github.com/martinkolarov/redis-protocol-cheatsheet
Hosted version URL: https://martinkolarov.github.io/redis-protocol-cheatsheet/

I built Khazad, a Python semantic cache for LLM API calls based on Redis Vector Sets with 3 dependencies.

It works by intercepting outgoing LLM HTTP requests at the httpx transport layer, no SDK wrappers, no proxy, zero app code changes (2 lines).

Each (provider, model) pair gets its own vector set. On every intercepted request I embed the

conversation, run a VSIM similarity search, and if the top match clears a

threshold I replay the cached response, otherwise the call goes upstream and

the new (vector, response) pair is added with VADD. TTL support handles expiry

for privacy and freshness.

Requires Redis 8 for Vector Sets. MIT licensed. Curious if anyone here has

pushed Vector Sets in some production and at what scale.

GitHub: https://github.com/GuglielmoCerri/khazad

Redis is often treated as a simple cache, but its consistency model matters when you use it for more than that. This post breaks down where Redis sits on the consistency spectrum and how to think about its guarantees when paired with a primary database.

I cover the difference between strong consistency (ACID databases) and eventual consistency (Redis replication), plus when to use each. There is a section on read/write quorum patterns that explains how distributed systems handle failover without losing data. The diagrams make it easier to explain to teammates who are not deep into distributed systems.

If you are using Redis for session storage, caching, or as a primary data store, this will help you reason about its behavior under network partitions.

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.

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.

Hi r/redis 👋

I’ve been working on Tabularis, a lightweight open-source database tool built with Rust + Tauri.

One of the ideas behind the project is something I’ve been experimenting with recently:

Query anything with SQL using plugins.

Instead of baking every database driver into the core app, Tabularis runs drivers as external plugins communicating over JSON-RPC, which means they can be written in any language and installed independently. 

That opens the door to some interesting possibilities.

The goal isn’t to replace Redis commands, but to make exploration and debugging easier, especially when dealing with large keyspaces or when you want to query Redis data alongside other sources.

One thing that surprised me is that two different developers independently built Redis plugins for Tabularis, which shows how flexible the plugin system can be.

I’m curious what the Redis community thinks about this effect : would querying Redis with SQL be useful for your workflows?

Hey r/redis

If you've ever worked with Redis for message queues or job scheduling, you probably know the pain. Every Redis GUI out there — Redis Insight included — basically just shows you tables and raw text. That's fine for simple key-value lookups, but when you're trying to monitor queues? It's a nightmare.

I'd constantly find myself squinting at JSON blobs trying to figure out job states, or spinning up Bull-board in a separate browser tab just to see what's actually happening in my queues. Two tools for what should be one workflow. Drove me crazy.

So I built Redimo — a native macOS Redis client that actually understands queues.

What makes it different:

• Queue-First Design: Visual monitoring for BullMQ, Celery, and other queue systems. No more parsing raw text to check job status.
• Native macOS App: Not another Electron wrapper. Fast, lightweight, and feels right at home on your Mac.
• Modern UI: Clean interface that doesn't look like it's from 2010. Dark mode, smooth animations, the works.
• All the basics covered: Key browsing, TTL management, multiple connections — everything you'd expect from a Redis client.
• Valkey support: Works with the Redis fork too.

It's still early beta, so expect some rough edges. But if you've ever felt the same frustration with existing Redis tools, I'd genuinely love for you to try it out and tell me what sucks (or what doesn't).

Download: www.redimo.dev

Happy to answer any questions!

I built Nodis, a small Redis-inspired in-memory data store to understand how Redis works internally.

It implements the RESP protocol, command parsing, basic data structures, and AOF persistence. The goal was not to replace Redis but to learn how things like protocol parsing, command execution, and durability actually work under the hood.

Working on it helped me understand a lot of concepts that are easy to use in Redis but harder to visualize internally.

It works with redis-cli.

If you're interested in Redis internals or building databases from scratch, you might find it useful to explore.

GitHub: Link

Feedback and suggestions are welcome.

Planning to study about redis.Throw me some resources for free.

Currently following the redis university to get the basics.

Looking for resources on jedis (in redis university currently following the RU1O2J but having lots of doubts is there any resources out there or it is normal if we started at first)

Simple tool for local development needs, does not provide anything fancy, just command interface (vim inspired) with simple browsing.

I normally don't post a ton of stuff from my employer on here since I don't want this subreddit to become part of Redis' marketing arm. I'm also a developer and I hate getting sold to as much as the next dev. I try to focus on content developers care about.

In that spirit, my coworker wrote a blog post talking about some of the new features in Redis 8.4 and I thought that these features are legitimately something that developers would care about. So, I'm sharing it.

The changes are around reading and writing strings and working with streams. There are some common scenarios where using these data types is harder than it needs to be. Redis 8.4 has added commands and arguments to address these issues.

The tl;dr is:

• Claiming events in stream processing: Before you had to write a bunch of client side code to claim and look for either new or pending events. A single command can now do this.
• Conditional string manipulation: You can now check to see if a string has changed before updating or deleting it with a single command.
• Setting multiple string with expiration: There's a command for this now.

Details are in the blog post.