Coming from Redis
If you have used Redis, many Clustron Zaris operations will feel familiar: you store a value under a key, read it back, delete it, set an expiry, and increment counters. Zaris is a .NET-first in-memory key-value store with coordination primitives built in, so several Redis patterns map directly onto a Zaris method. Others differ in shape — most notably that locks, leases, counters, watch, and transactions are first-class APIs rather than patterns you assemble yourself.
This article maps common Redis commands to their Zaris equivalents and is honest about where the two diverge. For the wider positioning of the two systems — deployment, language reach, and maturity — see Clustron vs Redis.
Command and pattern mapping
Every method below is asynchronous and returns a result object you inspect (Zaris does not throw for expected outcomes such as a missing key). The Redis command on the left is the closest analogue, not an exact match — read the differences section before assuming behavior carries over.
| Redis | Clustron Zaris | Notes |
|---|---|---|
GET key | GetAsync<T>(key) | Returns a KvResult<T>; check IsSuccess and read Value. A missing key is KvStatus.NotFound, not an exception. |
SET key value | PutAsync<T>(key, value) | Overwrites by default. result.IsUpdate tells you whether an existing value was replaced. |
SET key value NX | PutAsync(key, value, Put.IfAbsent()) | Writes only when the key is absent; a rejected conditional write reports KvStatus.Conflict. |
SETEX key seconds value / SET key value EX seconds | PutAsync(key, value, Put.WithTtl(...)) | Attach the TTL at write time. See TTL and expiration. |
DEL key | DeleteAsync(key) | Safe on a missing key. Check result.Mutated to know whether it removed anything. |
INCR key / INCRBY key n | Counters.AddAsync(key, n) | Atomic on the server. Use 1 for INCR. |
DECR key / DECRBY key n | Counters.AddAsync(key, -n) | Pass a negative delta to decrement. |
GET on a counter | Counters.GetAsync(key) | Reads the current counter value. |
SET a counter to a fixed value | Counters.SetAsync(key, value) | A blind overwrite — use it only to seed or reset, never to increment. |
SETNX lock / Redlock (distributed lock) | Locks.AcquireAsync(name, ttl) | Returns a lock handle, or null when another client already holds it. Backed by a lease, so it releases automatically if the owner crashes. See Locks. |
| Keyspace notifications / pub-sub on changes | Watch.WatchKeyAsync(...) / Watch.WatchPrefixAsync(...) | Push-based change events for a single key or a key prefix. See Watch. |
SCAN / KEYS prefix* | Scan.ScanAsync(new KeyRange { Prefix = "..." }) | Streams keys under a prefix; no index required. See Scan and query. |
| Secondary lookups (find by field) | Scan.SearchAsync(query) | Indexed queries over labels you attach at write time — filter, sort, and page. Redis has no direct equivalent. |
EXPIRE key seconds | ExpireAsync(key, ttl) | Resets a key's TTL in place. See the in-process caveat below. |
TTL key | GetTimeToLiveAsync(key) | Returns the remaining TTL, null when the key has no TTL, and KvStatus.NotFound when absent. |
PERSIST key | PersistAsync(key) | Removes a key's TTL so it never expires. Same in-process caveat as ExpireAsync. |
DBSIZE | CountAsync() | Returns the number of keys the store holds. |
ExpireAsync and PersistAsync route through the partition map and are only served by a fully initialized cluster node. In in-process mode they return KvStatus.Unavailable ("partition map not initialized"). If you run in-process, set a key's TTL at write time with Put.WithTtl instead; GetTimeToLiveAsync reads the remaining TTL in both modes. See In-process and distributed modes.
Key differences
The mapping above gets you moving quickly, but Zaris is not a drop-in Redis replacement. Keep these differences in mind.
- The client is .NET only. Redis has clients in nearly every language; Zaris exposes a native .NET async client and nothing else. If services in other languages must share the store, Zaris does not fit.
- Coordination primitives are first-class, not recipes. In Redis you build distributed locks (Redlock), leader election, and presence out of
SETNX, expirations, and Lua. Zaris ships these as APIs: locks, leases, counters, watch, and transactions. You call them directly rather than assembling them. - No Lua scripting. There is no server-side scripting surface. Where you would reach for a Lua script to make a multi-step change atomic, use a transaction or an atomic primitive such as a counter or lock.
- The data model is key to value, typed by serialization. A value is any type the client can serialize (see Serialization). Zaris does not provide Redis-style server-side data structures — there are no lists, sets, hashes, or sorted sets. Model those yourself: use separate keys (optionally under a shared prefix you scan), attach labels for indexed queries, and use counters for shared numbers. There is no
LPUSH,SADD,HSET, orZADDequivalent. - In-memory, but with a memory ceiling and eviction. Like Redis, Zaris keeps data in RAM. Each node is capped by a memory ceiling and evicts to stay within it, so plan for a bounded store rather than unbounded growth. See Memory and eviction.
Before and after: set with expiry, then read
A common Redis snippet writes a value with a 30-second expiry and reads it back:
SET session:abc123 active EX 30
GET session:abc123
The Zaris equivalent attaches the TTL through Put.WithTtl and reads with GetAsync<T>, checking the result before using the value:
await client.PutAsync(
"session:abc123",
"active",
Put.WithTtl(TimeSpan.FromSeconds(30)));
var result = await client.GetAsync<string>("session:abc123");
if (result.IsSuccess)
{
Console.WriteLine(result.Value);
}
Before the 30 seconds elapse, IsSuccess is true and Value holds your data. After expiry the key reads as absent: IsSuccess is false and Status is KvStatus.NotFound. Always branch on IsSuccess rather than assuming the key is present.
Next steps
- Basic operations for the full Get/Put/Delete surface and how to read a
KvResult. - Coordination model for the primitives that replace Redis coordination recipes.
- Clustron vs Redis for deployment, language reach, and maturity trade-offs.