Why teams use it
Consensus mechanics without handing your system over to a black box
Kommander is a library, not a finished database product. That is the point: it gives you the hard distributed-systems machinery while keeping your service architecture, data model, and APIs in your hands
Spread writes across partitions
Different partitions can have different leaders, so one node does not have to own every write in the cluster.
Keep control of your domain model
Kommander gives you consensus, WAL durability, and leader election. Your service keeps the API, schema, authorization, and business logic.
Run it where your service already runs
Use it as a library inside an ASP.NET Core host instead of standing up a separate control-plane product just to coordinate state.
Choose the durability and transport path
Use RocksDB or SQLite in production, in-memory adapters in tests, and gRPC or REST depending on how your cluster is hosted.
Scale partitions at runtime
Create, split, merge, and remove user partitions without restarting the cluster, with generation fencing to protect callers from stale routing.
Change cluster membership safely
Add nodes as learners, promote them after catch-up, and remove members through the committed system partition roster instead of trusting discovery snapshots.
Debug real runtime behavior
Queue-depth metrics, operation latency, WAL batching telemetry, stale-completion counters, and deterministic simulation tooling make failures easier to explain.
What it is
A serious foundation for replicated control-plane work
Use Kommander when several machines need to agree on the same ordered stream of decisions and another node must be able to continue safely after a failure.
Good fit
- Replicated control planes
- Partitioned metadata services
- Leader-owned workers and schedulers
- Workflow and job coordination
- Embedded coordination inside .NET services
Not the target
- A finished database product
- A drop-in cache or queue
- Eventually consistent fire-and-forget workloads
- Single-node applications that do not need quorum safety
What you get
The value is not just Raft. It is the runtime around Raft
Partition executors, fair schedulers, WAL adapters, transport choices, lifecycle APIs, security controls, and diagnostics make the library usable in real services instead of only in toy examples.
Elastic partitions
Create partitions for new workloads, split hot ranges, merge cooled ranges, and fence stale callers with partition generations while your service keeps ownership of state-transfer behavior.
Read the partition guideDynamic membership
Join new nodes as non-voting learners, promote them after they catch up, and remove members through a committed roster on the system partition so quorum is based on consensus, not discovery.
Read the membership guideOperational visibility
Metrics and logs explain queue pressure, operation latency, WAL batching, stale completions, and election behavior, while deterministic simulation helps reproduce timing-sensitive failures.