Inside Kahuna
Coordination, in motion.
Start with three everyday tasks: claim a job, save a value, and get the next invoice number. Follow each request to see what Kahuna does.
Both apps ask for the same lock
App A and App B both ask to lock “invoice-2048”. Their requests reach the Kahuna server in charge of that lock: its leader.
Same lock: invoice-2048Two apps. One lock. One winner.
Both app nodes want to process the same invoice. A lock lets only one own the job at a time.
The lock’s owner is copied across Kahuna servers. Both apps get an answer from the same leader.
Learn about locksWhy Kahuna
Simplify coordination
One owner, consistent state, and ordered IDs for your distributed workflows.
One worker per job
Use leases and fencing tokens to give one worker ownership of a job or tenant.
Consistent shared state
Read current revisions and use transactional compare-and-set for workflows like rate limiting.
Safe, ordered IDs
Allocate numbers and ranges across nodes without races, with idempotent retries.
Custom C# logic
Run trusted C# functions inside Kahuna Script transactions for validation and business rules.
Faster reads, safe failover
Over 116k read requests per second on a local three-node cluster with in-memory storage, plus built-in replication and failover.
See benchmark details →Your choice of storage
RocksDB for heavy writes, SQLite for smaller deployments, or memory for tests and temporary state.
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
- Custom C# functions inside transactions
- Multi-step workflows with compare-and-set
- Services that need quorum-backed coordination
- MIT-licensed Kahuna with no proprietary runtime fees
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
- .NET
- TypeScript
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);
import { KahunaClient } from "kahuna-client";
await using client = new KahunaClient({
endpoints: [
"https://kahuna-1.internal:8082",
"https://kahuna-2.internal:8082",
"https://kahuna-3.internal:8082"
]
});
await using jobLock = await client.acquireLock("jobs/invoice-2048", {
expiry: 30_000,
wait: 5000,
retry: 200
});
if (jobLock.acquired) {
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.