Skip to main content

Open source · .NET · self-hosted cluster

The distributed coordination layer for .NET

Kahuna is a self-hosted server cluster that gives your services distributed locks, a consistent key/value store, and ordered ID sequences — like etcd or ZooKeeper, but built for .NET. One node owns the work, writes stay ordered, and another node takes over safely on failure.

Locks with fencing tokens
Persistent and ephemeral state
Distributed sequence allocation
RocksDB, SQLite, or memory

Why Kahuna

Solve coordination problems directly

Use it when the application needs one owner, consistent shared state, or safe ordered allocation

Stop double processing

Use leases and fencing tokens when only one worker may own a job, tenant, or background task.

Keep shared state consistent

Store revisions, compare values, and read the latest state without building your own replication layer.

Allocate ordered IDs safely

Generate invoice numbers, tickets, offsets, or reservation ranges without races across nodes.

Connect to a replicated cluster

Point clients at one or more Kahuna endpoints and let the cluster handle replication, leader election, and failover.

Pick the storage path

RocksDB fits write-heavy clusters. SQLite fits smaller persistent deployments. Memory fits tests and temporary state.

Build workflows, not glue code

Rate limiting, leader-owned jobs, idempotent allocation, and transactional compare-and-set sit on top of the same model.

Where it fits

Use it for shared ownership and control-plane work

Fewer duplicate workers, fewer stale writes, fewer homegrown coordination paths

Good fit

  • Distributed locking for critical sections
  • Reliable shared configuration and metadata
  • Ordered ID allocation across nodes
  • Multi-step workflows with compare-and-set
  • Services that need quorum-backed coordination

Not the target

  • A general-purpose analytics database
  • A document store for large unstructured datasets
  • Fire-and-forget eventually consistent pipelines
  • Single-node apps that do not need quorum or leader election

Example

What using it looks like

Start a node, pick storage, and claim a resource

Cluster client

using Kahuna.Client;

var client = new KahunaClient(new[]
{
"https://kahuna-1.internal:8082",
"https://kahuna-2.internal:8082",
"https://kahuna-3.internal:8082"
});

await using KahunaLock jobLock = await client.GetOrCreateLock(
"jobs/invoice-2048",
expiry: TimeSpan.FromSeconds(30),
wait: TimeSpan.FromSeconds(5),
retry: TimeSpan.FromMilliseconds(200)
);

if (jobLock.IsAcquired)
await ProcessInvoice(2048);

What this buys you

One worker owns the job. The cluster replicates the lock state, and the lease expires if the owner dies or stops renewing it.

Clients can connect through any healthy endpoint while Kahuna handles consensus, failover, and the ordered write path behind the API.