In-process and remote
Clustron Zaris runs in two ways: in-process (embedded in your application) and remote (connected to a cluster). This article explains how the two differ, when to use each, and how to switch between them.
Both use the identical client API and programming model. You write your code once, and the choice between in-process and remote is expressed entirely by which connection string you use — zaris://inproc/store for embedded, zaris://host:port/store (or zariss:// for TLS) for a cluster. Because only the string changes, you can start in-process during development and move to a cluster in production without touching application code.
In-process
An in-process store runs inside your application's own process. No separate server or network connection is involved, and data is held in memory. You select it with the reserved host inproc:
zaris://inproc/orders
Use in-process when you want to run without infrastructure:
- Local development, where the store starts and stops with your application.
- Unit and integration testing, where you need a store but not a cluster.
- Single-instance applications that don't share data across processes.
Because there is no network hop, in-process is the fastest way to run the store. An in-process store cannot use TLS — there is no network connection to secure.
Remote
A remote connection reaches a store running across a cluster of nodes. A node is a single running instance of the store, typically one per machine. Nodes communicate over the network to replicate data and coordinate work between application instances. You select it by listing one or more seed hosts:
zaris://node-a:7861,node-b:7861/orders
zariss://node-a:7863/orders?ca=/etc/zaris/ca.pem
Comma-separated hosts are a seed list the client uses to discover the rest of the cluster and to fail over. Use remote when a single process is not enough:
- Production systems that need high availability.
- Applications that run as multiple instances and must share state.
- Workloads that must scale across more than one machine.
Choose a form
The following table compares the two so you can decide which fits a given environment.
| Aspect | In-process | Remote |
|---|---|---|
| Connection string | zaris://inproc/store | zaris(s)://host:port/store |
| Execution | Inside your application process | Across multiple nodes |
| Network | None | Required |
| TLS | Not available | Available via zariss:// |
| Setup | None | Installation required |
| Scale | Single instance | Multiple instances |
| Coordination | Local to the process | Shared across instances |
The mental model to keep is "in-process today, remote tomorrow." Build and test with zaris://inproc/..., then switch to a zaris://host.../... string when you need availability or scale. The same code path serves both.
Switch between them
You select in-process or remote by the connection string, not by code. Keep the string in the ConnectionStrings section and vary its value per environment (see Getting a client).
An in-process store:
{
"ConnectionStrings": {
"orders": "zaris://inproc/orders"
}
}
A remote cluster — same key, different value:
{
"ConnectionStrings": {
"orders": "zaris://node-a:7861,node-b:7861/orders"
}
}
The application code that registers and calls the store is identical in both cases:
services.AddClustronZaris(configuration, "orders");
var client = await provider.GetAsync("orders");
await client.PutAsync("key", "value");