Clustron Zaris
Clustron Zaris is a distributed key-value store with built-in coordination primitives. This article introduces what Zaris does, how you run it, and where to go next.
A key-value store keeps data as keys mapped to values. Zaris distributes that data across nodes and adds primitives — locks, leases, counters, watches, and transactions — that let application instances coordinate with each other. You use one .NET client for both the data and the coordination, so you don't build that coordination logic yourself.
Zaris clusters on Nodus, and is secured and observed by its built-in security and metrics layers.
What Zaris provides
Zaris pairs a distributed store with a small set of coordination primitives. You reach all of them through the same client.
- Key-value storage. Store and retrieve values by key, with optional expiration.
- Distributed locks. Serialize access to a shared resource across instances.
- Leases. Hold time-bound ownership that a holder renews, and that expires if the holder stops.
- Counters. Increment and read a shared value atomically.
- Watches. Receive events when keys change, so instances react to updates instead of polling.
- Transactions. Apply a group of operations atomically, with optimistic conflict detection.
Cluster-level leader election — choosing one leader among service instances — is provided by Clustron Nodus, which Zaris uses internally for clustering. It is not a Zaris key-value primitive.
How you run Zaris
Zaris runs in two ways that share the same client API. A client is created from one thing: a connection string — its scheme and hosts decide whether the store is embedded in your process or spread across a cluster. Because only the string changes, the same application code runs in both.
| Form | Connection string | Where it runs | Use case |
|---|---|---|---|
| In-process | zaris://inproc/store | Embedded in your application process | Development, testing, and single-instance apps |
| Distributed | zaris://host:port/store | Across a cluster of nodes | Production systems that need coordination or scale |
Run in-process
An in-process store uses the reserved host inproc and runs inside your process — no server or cluster required. Register the connection string and resolve a client:
using Clustron.Zaris.Client.DependencyInjection;
using Microsoft.Extensions.DependencyInjection;
var services = new ServiceCollection()
.AddClustronZaris("demo", "zaris://inproc/demo")
.BuildServiceProvider();
var client = await services
.GetRequiredService<IZarisClientProvider>()
.GetAsync("demo");
Connect to a cluster
To reach a running cluster, change only the connection string — zaris://host:port/store (or zariss:// for TLS), where comma-separated hosts are seeds and the path is the store name:
using Clustron.Zaris.Client.DependencyInjection;
using Microsoft.Extensions.DependencyInjection;
var services = new ServiceCollection()
.AddClustronZaris("demo", "zaris://localhost:7861/demo")
.BuildServiceProvider();
var client = await services
.GetRequiredService<IZarisClientProvider>()
.GetAsync("demo");
Because the connection string is the only difference, you can start in-process during development and move to a cluster in production without changing application code.
Manage a cluster
You create and operate clusters with the Zaris PowerShell cmdlets. You connect to a set of managers with a workspace, then create and start stores.
New-ZrWorkspace prod @('localhost:7801') -Activate
New-ZrStore -Name TestStore -PartitionsPerNode 2 -ReplicationFactor 1 -BaseClusterPort 7811 -BaseClientPort 7861
Start-ZrStore TestStore
The cmdlets also cover monitoring, metrics, and diagnostics. The Admin guide covers these tasks in full.
Where Zaris fits
Zaris suits patterns that need shared state and coordination across processes or machines.
- Distributed locking and mutual exclusion between service instances.
- Shared configuration that every instance reads consistently.
- Distributed job queues and work coordination.
- Rate limiting with shared counters.
- Caching with automatic expiration.