What is Clustron?
Clustron is a family of composable .NET building blocks for distributed systems. This article explains the problems each block solves, how the blocks compose into the flagship distributed key-value store, and where to start based on what you need.
Each block solves one hard part of running software across more than one process, machine, or container — forming a cluster, authorizing callers, measuring what's happening, and storing shared state — and each is a NuGet package you embed in your own application. There is no external coordinator to operate (no ZooKeeper, etcd, or Consul), no separate control plane to babysit, and nothing that forces you to adopt the whole stack at once.
You can take a single block on its own, or compose several. The flagship product, Clustron Zaris, is what you get when all of them are composed into one system: a distributed key-value store.
The problem Clustron solves
A single-process application has easy answers to hard questions. Who is in charge? This process. Is my collaborator alive? It's the same process. Where is the data? In memory, right here.
The moment your application runs as more than one instance — for scale, for availability, or because it lives in containers — every one of those answers becomes a distributed-systems problem:
- Coordination. Which instance runs the singleton job, and how do the others find out when it fails?
- Membership and failure detection. Who is in the cluster right now, and how do you tell "slow" from "gone"?
- Authorization. A request arrives at any instance — how does each one decide, consistently, whether the caller may perform the action?
- Observability. What is the real per-node throughput and error rate, cheaply enough to measure on the hot path?
- Shared state. Where does data live so that every instance sees a consistent view, survives a node loss, and scales as you add capacity?
These problems are famously easy to get almost right and famously expensive to get actually right. Clustron provides each answer as a tested, embeddable component so you build on them instead of rebuilding them.
The building blocks
The diagram shows how Nodus composes into Zaris, and how Nodus is also usable on its own.
Nodus — clustering and messaging core
Nodus gives a process everything it needs to join a peer-to-peer cluster, agree on a leader, exchange typed messages point-to-point or cluster-wide, and observe the health of its peers — with no external coordinator.
Use it directly whenever a set of processes must discover each other, elect a coordinator, and stay in agreement through failures: a leader-only scheduler, a work distributor, a cache that needs to invalidate peers. Nodus is the foundation Zaris clusters on, and it is fully usable on its own.
See the Nodus overview.
Zaris — distributed key-value store
Zaris is the flagship: a distributed, in-memory key-value store. It clusters on Nodus and adds partitioned storage, replication, transactions, watches, leases, distributed locks, counters, TTL, and a management and web-console control plane on top.
Security is built in — mutual TLS, offline-verified bearer tokens, and role-based access control (RBAC) that is deny-by-default — so authorization is answered locally at every enforcement point without a per-request call to a central server. Observability is built in too — high-frequency operational metrics (request rates, operation counts, gauges, and .NET runtime stats) recorded in a rolling time-window registry that is cheap on the hot path and exported over OTLP.
Use it when you need a distributed cache or a coordination-aware data store that a team can run in production, in-process for development and remotely at scale.
See the Zaris overview.
How the blocks compose
The blocks are layered, not tangled. Zaris depends on Nodus, and Nodus is useful on its own.
| Layer | Block | Depends on | Usable standalone? |
|---|---|---|---|
| Application data | Zaris | Nodus | It is the composed product |
| Coordination | Nodus | — | Yes |
This is a deliberate design choice: you are never forced to adopt the whole family. If you only need clustering, take Nodus. When you need a distributed store that already has security, metrics, and coordination wired together and hardened, take Zaris.
Design principles
Everything in Clustron follows the same handful of principles, so the blocks feel like one family.
- Embeddable, not operational. Each block is a library you reference, not a server you deploy. Zaris adds an optional management service and console, but the primitives themselves run inside your process.
- No external coordinator. Nodus forms and heals a cluster on its own. There is no ZooKeeper, etcd, or Consul to stand up, secure, and keep alive alongside your app.
- Offline-first where it counts. The security layer verifies tokens and evaluates policy locally, with a change-watch, so authorization does not add a network hop to every request. Metrics are recorded to an in-process registry, not a remote collector.
- Broad .NET reach. The core abstractions target
netstandard2.0, so they run on .NET Framework 4.8 and .NET 8+ alike; the richer adapters (ASP.NET Core, exporters, hosts) targetnet8.0. - Deny-by-default and fail-loud. Security refuses what it cannot prove; provisioning throws rather than silently degrading. The safe outcome is the default.
Where to start
Pick your entry point by the problem you actually have:
- A distributed cache or KV store — start with Zaris and its getting-started guide. You can run it in-process in a few lines, then move to a real cluster.
- Leader election, failure detection, or peer messaging — start with Nodus.
- Understanding how it all fits together first — read The Clustron family.