4 posts tagged with "Redis"

Today we're shipping Zaris 2.0.0 — the biggest release since Zaris reached general availability, and the first with a major version bump. It turns Zaris from a fast, replicated key/value store into a full data-structure server: native hashes, lists, sets, sorted sets, pub/sub, and Redis Streams, all partitioned and replicated the same way your keys already are.

And it opens the door to everyone else. Every node can now expose a Redis-protocol (RESP) front-end, so an application in Python, Ruby, Java, Go — any language with a Redis client — can point at Zaris and use it as a drop-in, without a native SDK and without rewriting a line.

The version number is a 2, not a 1.x, for a reason: 2.0.0 changes the wire. Read the upgrade note below before you roll it out.

Zaris is a distributed key/value store built natively for .NET. Its first-class clients speak an efficient binary protocol, and if your stack is .NET, that's the path you want — real async APIs, .NET types, coordination primitives, IDistributedCache and HybridCache drop-ins.

But most systems aren't only .NET. There's a Python service doing data work, a Go sidecar, a Ruby job runner, a Node gateway. Rewriting all of them onto a new client to try a new store is a non-starter. So in 2.0.0, every Zaris node can also expose a Redis-protocol (RESP2) listener: point an existing Redis client at it and use Zaris as a drop-in key/value store, in any language, without changing a line of client code.

This post is about how that front-end actually works — the routing model, the data model, the failover models, and exactly which commands are in and out.

Redis is fast. It is also, by design, single-threaded on the data path: one event loop, one core, one command at a time. That's a genuinely good design — it makes Redis simple to reason about and removes a whole category of concurrency bugs. But it has a ceiling you can't buy your way out of. Give a single-event-loop engine a 4-core box, an 8-core box, a 32-core box, and read throughput lands in the same place. The extra cores sit idle.

Zaris takes the other road. Keys are partitioned and each partition has an owner, so reads for different keys land on different cores and run at the same time. The result is throughput that moves when you add cores — instead of a flat line, a slope.

If your .NET services already talk to Redis, moving to Zaris doesn't have to be a rewrite. Zaris is a distributed, in-memory, replicated key/value store built natively for .NET — and as of 2.0.0 it speaks two protocols at once: its own efficient binary protocol for first-class .NET clients, and a Redis-compatible RESP2 front-end that any Redis client in any language can point at.

That gives you two honest migration paths, and they're not mutually exclusive. You can start with the zero-change RESP path to get Zaris under load today, then adopt the native client where it pays off. This post walks both, and gives you a clear rule for picking.