Skip to main content

Distributed cache for .NET

A distributed cache keeps shared, fast-access data in memory across several processes or machines so that every instance of your application sees the same values. This article explains what a distributed cache is, when a .NET application needs one, and how Clustron Zaris fills that role.

What a distributed cache is​

A cache stores computed or fetched values in memory so you don't pay to produce them again. A distributed cache spreads that memory across more than one node and makes the cached data reachable from any instance of your application.

The distinction matters once your application runs as more than one process. An in-process cache lives inside a single instance: each instance has its own copy, copies drift apart, and none of them survives a restart. A distributed cache holds one logical dataset that every instance reads and writes, so a value written by one instance is visible to the next request even if a different instance handles it.

When you need one​

Reach for a distributed cache when your application runs as multiple instances — for scale, for availability, or because it lives in containers — and those instances need a shared, consistent view of hot data. Typical workloads include:

  • Session state, so any instance behind a load balancer can serve a user's next request.
  • API and query response caching, so an expensive result computed once is reused across the fleet.
  • Configuration and feature flags, so a change propagates to every instance without a redeploy.
  • Shared application state, such as counters or derived values that several instances update.

How Clustron Zaris serves as a distributed cache​

Clustron Zaris is a distributed, in-memory key-value store for .NET. As a cache, it gives you the parts you expect from a caching tier:

  • Distributed key-value storage partitioned across nodes, so capacity grows as you add nodes.
  • Horizontal scaling across a multi-node cluster.
  • Time-to-live (TTL) expiration, so cached entries age out on their own.
  • Asynchronous .NET client APIs for reads and writes.
  • A cluster-wide view of the data, so any node can serve a request for any key.

You install it as a NuGet package and talk to it from the native .NET client. In development you can run the store in-process — embedded in your application with no separate server — and later point the same client code at a real remote cluster without rewriting it.

tip

Start in-process while you build and test, then switch to a remote cluster for production. The client API is the same in both modes, so the move is a configuration change, not a rewrite.

More than a cache​

Zaris is a coordination-aware store, not only a cache. Alongside get and set, it exposes primitives that a plain cache does not:

  • Distributed locks, so only one instance runs a critical section at a time.
  • Transactions, so several operations apply atomically.
  • Watch notifications, so a client reacts to a key changing instead of polling.
  • Atomic counters and leases, for shared numeric state and ownership with expiry.

These let you use one store for both cached data and the coordination logic that usually needs a second system. For a deeper treatment of those primitives, see the coordination guide below.

Next steps​