Skip to main content

Architecture

Clustron Zaris is a distributed key-value data engine built for high-throughput, low-latency workloads in microservice environments. This page is a high-level tour of the engine — how a node is put together and how nodes form a cluster — so you can reason about where your operations run and why the system behaves the way it does.

Looking for the deep dive?

This page tours the engine at a conceptual level. For diagram-rich, up-to-date coverage of the cluster — the manager and nodes, partitioning and replication, deployment models, security and TLS, scaling, and the web console — see the Architecture & Operations section.

Design goals​

Clustron Zaris is a distributed data foundation, not a simple cache. Its structure follows from a small set of goals that shape every layer below:

  • Horizontal scalability, so you add capacity by adding nodes.
  • A clear separation between control responsibilities and data responsibilities.
  • Extensible internal engine components that evolve without a rewrite.
  • Predictable performance under load.
  • Instance-level isolation, so instances do not interfere with each other.

Clustron Zaris architecture​

Clustron Architecture

Each node runs as an independent process and takes part in cluster coordination. The rest of this page works from the inside out: first the split between control and data, then the components inside a node, then how nodes form a cluster.

Control plane and data plane​

Clustron Zaris separates the work of serving data from the work of managing the cluster. Keeping these planes distinct is what gives the system both operational clarity and room to scale, because each plane can be reasoned about and tuned on its own.

Data plane​

The data plane handles every request that touches your data. It is the path your application exercises on each operation, and it is tuned for throughput above all else.

It is responsible for:

  • Key-value operations (Get, Put, Delete)
  • Prefix queries
  • Watch subscriptions
  • TTL enforcement
  • Index lookups
  • Query execution
  • Lease and locking primitives
  • Counter operations

To keep that path fast, the data plane is optimized for throughput, minimal garbage-collection pressure, efficient asynchronous networking, and low-overhead serialization.

Control plane​

The control plane manages the cluster itself rather than the data in it. It runs when stores and instances are created, configured, and torn down — not on every request.

It is responsible for:

  • Store creation
  • Instance lifecycle management
  • Cluster configuration
  • Port management
  • Instance isolation
  • Node startup and shutdown
  • Configuration templates

Because of this separation, each Zaris instance runs independently, carries its own configuration, keeps isolated logging, and can be deployed multiple times per host.

Inside a node​

A single Clustron Zaris node is built from a set of focused engine components. Each one owns a distinct part of a request's journey, which is what lets the engine stay fast and evolve piece by piece.

Request pipeline​

The request pipeline is the front door: it receives client requests and routes them to the right engine component. It is designed for asynchronous I/O efficiency, minimal context switching, backpressure handling, and structured error propagation, so the node stays responsive when load spikes.

Segment store​

The segment store is the core in-memory storage engine — where your keys and values actually live. It handles key partitioning, concurrent access, data layout, and efficient memory usage. Its segment-based partitioning is the key idea: work is split across segments so many operations proceed concurrently without a single global lock.

Index manager​

The index manager accelerates queries so they do not fall back to scanning every key. It provides equality indexing, range indexing, and efficient lookup paths, and it maintains those indexes alongside primary storage so query operations avoid full scans.

Expiration engine​

The expiration engine enforces TTL. It uses a TimeWheel-inspired model, which schedules expirations in O(1) time and keeps cleanup cost predictable instead of scaling with the number of keys. This avoids per-key timer overhead and expensive scanning, so performance holds up under large TTL workloads.

Watch engine​

The watch engine powers reactive applications by delivering changes as they happen. It supports subscriptions to key prefixes, delivers events on mutations, offers a snapshot followed by live events, and propagates events in order — the foundation for building systems that react rather than poll.

Lease and lock engine​

The lease and lock engine provides the distributed coordination primitives: leases, lock acquisition, expiry-based coordination, and safe release. These are the building blocks that higher-level workflows — exclusive access, leader election, presence — are assembled from.

Counter engine​

The counter engine maintains atomic distributed counters with increment, decrement, read, and TTL support. It is built for metrics, throttling, and coordination scenarios where many clients update the same number safely.

The cluster model​

Clustron Zaris nodes form a single logical cluster. The cluster is designed so that operations stay consistent within a node's ownership boundaries while the system as a whole scales horizontally.

Its defining characteristics are:

  • Peer-to-peer coordination between nodes
  • Node-aware routing of requests
  • Failure detection
  • Rebalancing as the cluster grows or shrinks, driven by elastic scaling (Add-ZrServer/Remove-ZrServer)
  • Configurable priority-based reconnect behavior

Clients are active participants in this model. Each client maintains a priority server list, a reconnect delay strategy, and failover handling, so it can keep working as node availability changes.

Multi-instance deployment​

Clustron Zaris supports running multiple instances on one machine. Each instance runs on its own port, keeps isolated configuration and logs, and can be started or stopped on its own. This makes it practical to partition resources, isolate environments, and run controlled multi-tenant deployments on shared hardware.

Networking​

The networking layer is built for high-throughput asynchronous operations, efficient socket usage, controlled connection lifecycles, and graceful failover. It deliberately avoids unnecessary abstraction layers, because every extra layer on the request path adds overhead the engine is trying to shed.

Scalability philosophy​

Clustron Zaris scales out rather than up. That choice drives the rest of the design: stateless client design, predictable memory behavior, controlled coordination overhead, and modular extensibility. The engine is structured so that new capability can be added without reworking the core — planned directions include advanced query capabilities, vector and similarity search, distributed job scheduling, and additional distributed primitives.

Observability​

Zaris ships with observability built in. Live per-store and per-node metrics stream through Watch-ZrStoreMetrics, the cluster reports its own health, and distributed tracing is available per store (New-ZrStore -Tracing) or on demand from a client (Enable-ZrTrace). See Monitoring for the full operational picture.

Design principles​

The architecture follows a consistent set of principles: performance first, predictability over abstraction, extensibility without rewriting the core engine, clear separation of responsibilities, operational clarity, and practical distributed-systems engineering.

Current status​

Clustron Zaris is in active development. Core engine stabilization and documentation are ongoing. A public open-source release of the core engine is planned for 2026 under a Business Source License.

Next steps​