Skip to main content

Core concepts overview

Clustron Zaris is a distributed key-value store with coordination primitives built in. This section gives you the mental models you need to design applications on it: what a store is, how keys and values behave, how data expires, what the system guarantees under concurrency, and how leases and coordination work.

What Clustron Zaris gives you​

Clustron Zaris combines three things that are usually separate systems:

  • A distributed key-value store, where you read and write values by key.
  • Coordination primitives — locks, counters, and watch — that let independent application instances work together safely.
  • Lifecycle management, where keys expire on their own and ownership of a resource is bound to time.

The payoff is that you reason about shared state, coordination, and cleanup through one API instead of stitching together a cache, a lock service, and a message bus.

tip

Hold this model in your head as you read the rest of this section: Clustron Zaris is shared state plus coordination plus lifecycle. Data is the shared state, leases and locks are the coordination, and TTL and expiry are the lifecycle.

The store is the unit you work against​

Every operation in Clustron Zaris runs against a store. A store is a logical cluster that holds your data and your coordination primitives, and it defines the boundary within which they are consistent. You never talk to individual nodes directly — you talk to a store, and the store presents itself as a single logical unit no matter how many nodes back it.

A store can run in two ways without any change to your code:

  • In-process, inside a single application, with no separate infrastructure.
  • Distributed, across multiple nodes on multiple machines, so instances can coordinate.

Because the API is identical in both, you can develop against an in-process store and deploy against a distributed one.

Data and coordination in one place​

The data side of a store is the key-value store: you put and get values by key, attach a time-to-live so entries clean themselves up, and group multiple operations into a transaction when they must apply together.

The coordination side lets multiple instances act as one system. Locks give you mutual exclusion so only one instance runs a critical section. Counters track shared numeric state with atomic updates. Watch delivers changes as they happen, so you react instead of poll.

These are not bolted on beside the data — they are built on the same keys, TTL, and lease machinery, which is why they behave predictably together.

Lifecycle awareness​

A plain cache stores values and forgets about them. Clustron Zaris tracks lifecycle: keys can expire automatically on a TTL, resources can be bound to a lease so they exist only while an owner keeps it alive, and failures are handled by letting expiry release ownership rather than leaving it stuck. This is what lets you build systems that recover on their own when a process crashes or a network link drops.

How the pieces fit together​

The following outline shows how the concepts stack up inside a store, from raw data at the top to coordination at the bottom:

Store
  ├── Keys & Values
  ├── TTL & Expiration
  ├── Leases (lifecycle control)
  └── Coordination (locks, counters, watch)

Each layer builds on the one above it: coordination primitives rely on leases, leases rely on the same expiry mechanism as TTL, and all of it lives inside a single store.

Next steps​