Skip to main content

Distributed In-Memory Cache Architecture, Explained

How a key becomes a partition becomes a node — the control plane, the data plane, and the membership that ties them together.

6.5 minWatch on YouTube ↗

Watch it, or read it

The full walkthrough below — every screen from the video, with the narration transcribed. Skim it, search it, or read it in your own language.

Distributed In-Memory Cache Architecture, Explained — screen 1 — Let us look under the hood. In the next few minutes, you will get the mental model of Zaris. How a distributed, in-memory cache for dot NET keeps your data fast, sharded across machines, and safe. Let us begin.

Distributed In-Memory Cache Architecture, Explained — screen 2 — So, what is Zaris. It is a distributed, in-memory, replicated key value store for dot NET. With coordination primitives — locks, leases, counters, watches, transactions — all behind one client. It lives in memory, for speed. And here is the important part. It is replication, not a disk, that keeps your data safe. The very same client and connection string runs it three ways. In process, in Docker, or on Kubernetes.

Distributed In-Memory Cache Architecture, Explained — screen 3 — A cluster has two planes. The control plane is the manager, the Management Service. It handles stores, membership, config, security, and metrics, and it backs the web console. But it is never on the request path. The data plane is your nodes. They hold the data in memory, and serve every request. Which means you can lose the manager entirely, and your data keeps right on serving.

Distributed In-Memory Cache Architecture, Explained — screen 4 — How does a key find its home? Deterministically. A key hashes into one of a fixed set of segments. Segments group into partitions. And each partition is owned by a node. Because it is all computed, any client works out the same route, with no coordination. Partitions carry stable code words — Amber, Onyx, Jade — so you can follow one as it moves. And the number of partitions is simply partitions per node, times the number of live nodes.

Distributed In-Memory Cache Architecture, Explained — screen 5 — Now, availability. The replication factor is how many copies of each partition you keep. With replication factor two, every partition has one primary, which serves reads and writes, and one replica, a hot standby. And they always live on different machines. So any single node can fail, and every piece of data is still there, on another. Factor three survives two failures.

Distributed In-Memory Cache Architecture, Explained — screen 6 — Watch what happens when a node drops. Node zero goes down, taking the Onyx primary with it. Immediately, the in sync Onyx replica on node three is promoted to primary. It is a runtime ownership change, not a repartition. Clients refresh their map and re route, and a fresh replica rebuilds in the background. No data loss. No downtime.

Distributed In-Memory Cache Architecture, Explained — screen 7 — So how does a request actually travel? The client learns the map from any seed node. The partitions, and who owns each one. Then it talks straight to the owner. One network hop. No proxy through the manager. Writes land on the primary, and replicate to the replica. Reads hit the primary too, so you always read your own writes. And if ownership has moved, the node simply says, Moved, and the client re resolves and retries. Automatically.

Distributed In-Memory Cache Architecture, Explained — screen 8 — And inside a single node? A tight pipeline. An async socket receives the request on the I O thread. It is decoded — framed, and MessagePack. Then handed to a worker pool. Sharded channels, a worker per shard, scaling with your cores. The router turns the key into a segment, and does an in memory lookup, and the response goes back out over T C P. It is lean. On four virtual C P Us, a single node serves around three hundred seventy thousand reads a second.

Distributed In-Memory Cache Architecture, Explained — screen 9 — How do the nodes find each other, and agree? Through Nodus, the built in clustering core. No ZooKeeper. No etcd. No Consul. The nodes form a full mesh. Every member connected to every other. Heartbeats flow constantly, and exactly one leader is elected per epoch. Discovery is built in. Zaris clusters itself.

Distributed In-Memory Cache Architecture, Explained — screen 10 — There is one question that shapes how you run Zaris. Who owns the node processes? In supervisor mode, the manager itself forks and owns the nodes. You create stores and push config at runtime, and you scale by adding a machine. In attach mode, an orchestrator — Docker, or Kubernetes — owns the nodes, and the manager observes and adopts them. You scale by changing the replica count. Same cluster, two operating models.

Distributed In-Memory Cache Architecture, Explained — screen 11 — And scaling is elastic. Add a machine, with Add Zaris Server, and it is lossless. The segments, carrying their keys, reshard onto the new node without rehashing, and clients pick up the new map transparently. The scaling unit is a whole machine, and every store grows to use it.

Distributed In-Memory Cache Architecture, Explained — screen 12 — Zaris does not stand alone. It is one of four cores. Zaris is the store, the data plane. Nodus is the clustering core, the peer to peer membership that means no external coordinator. Keyvus is security and identity — tokens, role based access, and the T L S trust fabric. And Numerous is the metrics core, low allocation, with OpenTelemetry export.

Distributed In-Memory Cache Architecture, Explained — screen 13 — Which gives you two windows onto the same truth. The web console, to operate without the terminal. Nodes, partitions by code word, the partition map, per node metrics. And OpenTelemetry, to stream traces, metrics, and logs into your own stack, over O T L P. Off by default. Zero overhead until you subscribe.

Distributed In-Memory Cache Architecture, Explained — screen 14 — So, Zaris in five ideas. Data lives in memory, split into partitions. Every partition is replicated across machines. Clients talk straight to the owner, in one hop. It clusters itself, with leader election and failover built in. And you add a machine, and it spreads, losslessly. Explore the architecture at clustron dot i o. Thanks for watching.

More videos

Getting Started — a Distributed Cache for .NET in Minutes

Securing a Distributed .NET Cache — Authentication & RBAC

TLS & Mutual TLS for a Distributed .NET Cache

Linear Scaling Benchmark — 1 → 2 → 3 Nodes, Live

Get started Subscribe on YouTube