Store
A store is the central unit you work against in Clustron Zaris. Every data and coordination operation happens inside a store, and the store defines the boundary within which those operations are consistent and isolated.
What a store is
A store is a logical cluster. It is a container for your data and your coordination primitives, and it is the boundary for consistency and lifecycle management — the scope within which keys, locks, counters, and leases relate to one another. You always interact with Clustron Zaris through a store; there is no lower level you address directly.
The same store abstraction works whether it runs inside one process or across many machines. What changes between those cases is the number of nodes behind the store, not how you use it.
One store, many nodes
In distributed mode, a store is backed by multiple nodes. A node is a single running instance of the store. The nodes share the store's data and coordination state and present themselves to you as one logical unit:
Store (TestStore)
├── Node 1
├── Node 2
└── Node N
Each node participates in the cluster, data and coordination state are shared across them, and the system behaves as a single store. You do not route requests to specific nodes yourself — clients can connect to any node, and the cluster coordinates behind the scenes.
In-process and distributed stores
The same store runs in two modes. In in-process mode it runs entirely inside your application, with no network communication and no external dependencies:
Application
└── Store (InProc)
In distributed mode the store runs across machines — for example Node 1 on machine A, Node 2 on machine B, Node 3 on machine C. The nodes communicate with each other, clients can connect to any of them, and the cluster maintains shared state. The API is identical in both modes, so the difference is where the store runs, not how you program against it. In-process and distributed modes covers the trade-offs.
Naming a store
Each store has a unique name, such as TestStore, orders, or cache. The name is the handle you use to create the store, connect clients to it, and resolve it from configuration. Because the name is how everything finds the store, keep it stable and descriptive.
A store is a boundary
The most important thing to understand about a store is that it draws hard boundaries. These boundaries are what make stores a unit of isolation you can reason about.
- Data boundary. Keys live within a store. Different stores never share data, and each store keeps its own key space. A key in one store is invisible to another.
- Coordination boundary. Locks, counters, and watches are scoped to a single store. There is no cross-store coordination — a lock in one store means nothing in another.
- Failure boundary. Failure and recovery happen within a store. Each store operates independently, so trouble in one does not spread to another.
Running multiple stores
Because each store is isolated, you can run several in the same environment — for example orders-store, inventory-store, and session-store. Each is managed independently, which lets you isolate workloads, scale a specific store on its own, and apply different configuration per store. This is the main reason stores are the unit of scale and modularity in Clustron Zaris: you partition your system along store boundaries and treat each store as its own concern.