8 posts tagged with "Redis"

Keyspace notifications are one of Redis's most useful features and one of its most quietly fragile. The idea is lovely: every time a key is written, deleted, or expires, the server publishes an event on a well-known pub/sub channel, and anyone who cares can PSUBSCRIBE and react — invalidate a cache, wake a worker, refresh a projection. No polling, no GET in a loop asking "has it changed yet."

The fragility is in the fine print. Redis keyspace notifications are fire-and-forget pub/sub, emitted by whichever node processed the command, to subscribers connected to that same node. In a clustered deployment that means a subscriber only hears about writes that happened to land on the node it's attached to, and if that node fails over, the subscription — and the stream of events it was carrying — goes with it. The feature works beautifully on a single box and gets subtle fast once there's more than one.

Zaris speaks the exact same protocol — CONFIG SET notify-keyspace-events, the __keyspace@0__ and __keyevent@0__ channels, a vanilla PSUBSCRIBE from any Redis client in any language. But the plumbing underneath is not a reimplementation of Redis's notifier. It's a thin bridge onto a feature Zaris already had: a native, cluster-wide, replicated watch. That changes what the notifications are worth.

Zaris exposes a Redis-protocol (RESP) front-end so any Redis client, in any language, can point at a Zaris cluster and use it as a drop-in store. But "any Redis client" hides a real problem: Redis client ecosystems do not agree on how to discover topology or how to recover when a node disappears. A plain client expects a single stable endpoint. A Sentinel-based client expects to ask a discovery service "who is the master?" A cluster-mode client expects hash slots and MOVED/ASK redirects.

If a store spoke only one of those dialects, a whole class of clients would be locked out. So the Zaris RESP front-end supports three failover models, each matching how a particular family of Redis clients already expects to work. You pick the model per deployment; the client behaves exactly as it would against real Redis.

One honest note up front, because it shapes everything below: all three models sit in front of the same replicated, partitioned Zaris store. The model you choose changes discovery and redirection semantics — how a client finds a node and what it does when one fails — not where your data actually lives.

Zaris already speaks in collections — hashes, lists, sets, and sorted sets that live on the server and replicate like any other key. Streams are the fifth kind, and they're the one that turns Zaris from a store into a piece of messaging infrastructure.

A Zaris stream is a real append-only log: entries get monotonic IDs, you can read ranges, and you can attach consumer groups so a pool of workers divides the log between them, tracks per-consumer pending entries, and acknowledges what it has processed. You can also do a blocking read — a consumer parks and waits until new entries arrive instead of hot-looping.

And because it's a native Zaris collection, the log is partitioned and replicated exactly like everything else. A stream survives a node failover, which is the whole reason to reach for durable messaging in the first place.

Zaris 1.x stored values. Zaris 2.0.0 stores collections. Hashes, lists, sets, and sorted sets are now first-class, server-side types with real, typed .NET APIs — and, just as importantly, they behave like everything else in the store.

That last part is what people usually get wrong. In a lot of systems, "data structures" are a client-side illusion: a library serializes a dictionary into a blob, Puts it, and calls that a hash. It works until two clients touch the same collection at once, or until you ask what happens on a failover. In Zaris, a hash is a hash on the server. It sits on the partition that owns its key, it replicates to that partition's replica, and it survives a node loss exactly the way a plain key does.

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.