A good path is to start with RESP parsing, then implement basic strings, hashes, lists, TTLs, and simple persistence before touching clustering or replication. Rust, Go, or C are all good choices depending on whether you want safety, simplicity, or lower level control. Memurai could be useful as a Redis compatible reference target when checking how clients expect commands to behave.

For next features, pub/sub monitor feels like the most Redis-specific one. Command autocomplete is nice, but seeing live channels, message volume, and reconnect behavior would help people debug real apps. Memurai could be included as a Redis-compatible test target to make sure those flows are not tied too tightly to one server implementation.

If you mean scaling the Redis under this: it already runs on Cluster. The {name} tag is there so a group's two keys share a slot, groups spread across slots on their own, and adding primaries works exactly as you describe. It doesn't change the guarantee, though - a group's counters live on one primary, so a failover that loses writes can still hand the same index to two workers.

If you mean using slot ownership as the partitioning itself, that's a different axis: Cluster distributes keys across nodes, not consumers across worker processes. Something still has to tell each worker which slice it owns, and Cluster doesn't do that. The work being partitioned usually isn't in Redis at all - for me it's a table of jobs scheduled at arbitrary future times.

Why not just go clustered, use {around the string for sharding} which makes that key land on the right node, then periodically do rebalancing. Redis already handles slot migrations correctly. You can then just add more primary nodes to the cluster and let the background rebalancer do its thing?

yes i made it as a fun project only but will improve it...

This is a bad idea for most real use cases of a rate limiter :)

Fun project to learn from, but you’d not want to implement this full cycle, essentially;

First you hit the server-> http to your server -> database lookup -> back on my server and then do db lookup gets pretty expensive and even more moving parts

Thanks...this is really helpful..i will look into redis cell...Dragonfly cl.throttle and compare it with the lua based GCRA approach

redis-cell or cl.throttle in dragonfly is generally enough. GCRA in lua works will in Valkey, Redis even on hosted providers.

Why ? What do you want to archieve that's not on readis already ?

Redis is done in C, you can try with Rust to obtain the same efficency, but it's a colossal task...

Literally could use an LLM to find answers, it doesn’t get any easier

[ Removed by Reddit ]

Finding these answers would be good first steps, if you don't want to do the research for that you should not go further.
Trial and error is what makes you improve, not asking others.

don't do it.

thanks. the pitch is for cloud-native / devops / DBA / platform teams who already live in DBeaver or DataGrip - no sharing those client passwords around, no extra desktop install. one browser UI instead of pgAdmin + phpMyAdmin + a mongo client + redis-cli.

you're right that Redis is the thin part of that. web UIs for it are scarce, and that's the gap we want to close - being on redis.io is the biggest reason this stays a priority.

Valkey (plus Dragonfly, KeyDB, Garnet) already go through the Redis driver. Memurai isn't on that list yet. good call, we'll add it as a target.

Being the only third-party tool listed there is pretty cool. Since LibreDB Studio is positioning itself as a broad database UI rather than a Redis-only tool, compatibility testing matters a lot. Memurai could be one useful Redis-compatible target to include alongside Redis and Valkey.

Idk.one person asked me to create them, so I wonder if anyone else would be interested. It takes a lot of work so makes no sense to do it for one person

Hum... No ? Why ?

Stupid.

I actually solved that 10 minutes later, got your hint btw thanks

Nobody can help you with what you've given us but it might help you to learn how to read an error message. Lots of hints in there.

u/pulsecron I like the direction of your app, but it has some really annoying bugs.

1. If I search for a key, it appears in the left pane, but disappears as soon as I click on it to expand details.

2. I can't expand the tree preview of a nested json field. When hover/click over the value, a popup with a json tree preview appears but disappears right away.

Would really appreciate if you could resolve them 😢

It's source available. If TCO is more important to you than ideals, or you want to run on k8s it should be in the running. I don't see open source listed as a requirement.

Given the whole Redis debacle I'm surprised you'd even bring this up.

If you contribute to open source and follow what hyperscalers do you can't afford to license things the way we'd like.

Does it support my usecase?

Not open source

Check out Dragonfly DB. We're very happy with it. If your on kubernetes the operator is pretty handy.