Skip to main content

Keys and values

Clustron Zaris stores data as key-value pairs: a key that identifies an entry and a value that holds its data. This is the most direct way to work with the system, and every higher-level feature — TTL, leases, coordination — is built on top of it.

Keys​

A key is a unique identifier for a value. Keys are strings, and each key belongs to exactly one store. Within a store a key is unique: writing to a key that already exists replaces its value rather than creating a second entry.

Keys typically encode structure in the string itself, using a separator to group related entries:

  • "user:1001"
  • "order:5002"
  • "session:abc123"

Values​

A value is the data associated with a key. A value can be any serializable type — Clustron Zaris serializes it for you, so you store and retrieve typed objects directly rather than managing bytes yourself. This means you can store a simple scalar or a full object with the same call:

await client.PutAsync("user:1001", new User { Name = "Ali", Age = 30 });

await client.PutAsync("count", 42);

Because retrieval is typed, you specify the type you expect when you read a value back, and Clustron Zaris deserializes into it.

Basic operations​

The three core operations are put, get, and delete. Put writes a value under a key, get reads it back, and delete removes it:

await client.PutAsync("key", "value");

var result = await client.GetAsync<string>("key");

await client.DeleteAsync("key");

These operations behave identically in in-process and distributed modes. The same code works whether the store runs inside your process or across a cluster, which is what lets you develop locally and deploy distributed without changes.

Designing keys​

How you name keys shapes how easily you can find, group, and reason about your data later. Two habits go a long way.

Use namespacing — a consistent prefix and separator — to group related entries, so user:1001, user:1002, and order:5001 cluster naturally by type. This structure is also what prefix-based features such as watch and prefix queries operate on, so a good scheme pays off beyond readability.

Keep keys predictable. Derive them from stable identifiers with a consistent pattern, and avoid random or ambiguous names, so any part of your system can construct the key for a piece of data without looking it up.

Keys are scoped to a store​

A key lives inside the store that holds it. Keys in one store are not visible in another, and each store maintains its own independent key space. This is why the store is the boundary for your data: two stores can use the same key name for entirely unrelated values without any collision.

Keys are more than storage​

A key in Clustron Zaris is not only a slot in a dictionary. The same keys can also take part in the system's lifecycle and coordination features:

  • TTL, so a key expires automatically after a set duration.
  • Leases, so a key exists only while an owner keeps its lease alive.
  • Coordination primitives — locks, counters, and watch — that build on keys.

Because these features all operate on the same keys, the value you store and the behavior around it stay in one place instead of spread across separate systems.

Next steps​