Coordination model
Clustron Zaris provides primitives that let independent application instances coordinate safely through shared state. This article explains the model behind locks, counters, and watch — what they are for and why they behave predictably under failure — so you can decide which one a given problem needs.
The core idea
Coordination in Clustron Zaris rests on three ideas working together:
shared state + controlled ownership + automatic recovery
The store holds the shared state, leases give ownership that is controlled and time-bound, and expiry provides automatic recovery when an owner fails. This is why coordinated applications behave predictably even when a process crashes: the same machinery that manages data lifetime also manages who is responsible for what.
The primitives are not separate subsystems bolted on beside the data. They are built on the layers you already know:
Keys → TTL → Leases → Coordination
Keys store the state, TTL manages its lifetime, leases manage ownership, and the coordination primitives build on top. Because they share one foundation, they compose cleanly and fail safely together.
The three primitives
Clustron Zaris gives you three coordination primitives, each answering a different question: locks answer "who may act", counters answer "how many", and watch answers "what changed".
Locks
A lock ensures that only one client can act on a resource at a time. Use one when a critical section must run exactly once across your whole system — to prevent duplicate job execution, ensure a single worker processes a task, or protect a shared resource from concurrent modification.
Locks give you exclusive ownership, and because they are backed by leases they are safe under failure: if the owner crashes, its lease expires and the lock is released automatically. There is no manual cleanup and no risk of a dead owner deadlocking everyone else.
Counters
A counter maintains shared numeric state that many clients update at once. Use one to track counts such as active workers, to enforce rate limits, or to collect distributed metrics.
Counter updates are atomic and consistent across nodes, so concurrent increments and decrements do not lose updates and you do not need any manual synchronization around them. This is the safe way to keep a running total that several instances contribute to — where a plain read-modify-write on a key would risk lost updates.
Watch
Watch lets a client observe changes to keys or key prefixes and react as they happen. Use it to respond to configuration changes, monitor state transitions, or trigger workflows the moment data changes.
Watch delivers real-time notifications, works across distributed nodes, and eliminates polling: instead of repeatedly checking for changes, your application is told about them. This turns a system from one that asks "has anything changed?" into one that reacts when something does.
Why one model matters
Built without a unified model, distributed systems tend to accumulate separate infrastructure — one system for locking, another for messaging, and hand-written glue to coordinate them. Clustron Zaris folds all of it into a single system with one consistent API, with safety and lifecycle management built in. You interact with locks, counters, and watch the same way you interact with data, and they inherit the same guarantees.