Aarkam / Aarkam Wiki / Architecture / Rokka Raft Consensus & Consistent Hash Ring
Distributed Fabric Architecture

Rokka Raft Consensus & Consistent Hash Ring

Distributed coordination, Raft MON consensus quorum, and topology mapping across failure domains.

Last updated: Sep 23, 2026

Rokka is Aarkam’s distributed control plane and coordinator fabric. It is responsible for orchestrating cluster state, maintaining consistent metadata, and dynamically mapping data chunk placement across physical nodes without centralized single points of failure.


1. Raft MON Consensus Quorum

The Rokka Coordinator layer operates as a distributed Raft consensus group composed of an odd number of peer nodes (typically 3 or 5 nodes):

       ┌────────────────────────┐
       │   Rokka.Coordinator 1  │ (Leader)
       │    HTTP: 7774 / 57774  │
       └───────────┬────────────┘
                   │ Raft Log Replication (mTLS)
         ┌─────────┴─────────┐
         ▼                   ▼
┌─────────────────┐ ┌─────────────────┐
│  Coordinator 2  │ │  Coordinator 3  │
│   (Follower)    │ │   (Follower)    │
└─────────────────┘ └─────────────────┘

Quorum Mechanics

  • Leader Election: Heartbeats are exchanged every 150ms. If the leader fails to respond within the election timeout (300ms), followers initiate an election.
  • Log Replication: State mutations (such as adding a node, registering a volume, or updating failure boundaries) are committed only after acknowledgment by a strict majority: \(\text{Quorum} = \left\lfloor\frac{N}{2}\right\rfloor + 1\)
  • Split-Brain Immunity: In a 3-node cluster, a single node loss leaves a working quorum of 2. Network partitions cannot produce divergent cluster states.

2. Dynamic Consistent Hash Ring

Rokka distributes chunks across storage nodes using a modified Consistent Hash Ring augmented with failure-domain awareness:

                  Node A (Rack 1)
                     [0° / 360°]
                       ● ─── ● Node B (Rack 2)
                     /         \   [60°]
                    /           \
     Node C (Rack 3) ●            ● Node A (v-node)
          [270°]    \           /   [120°]
                     \         /
                       ● ─── ● Node B (v-node)
                  Node C       [180°]
                  (v-node) [210°]

Virtual Nodes (v-nodes)

To prevent hot spots and uneven disk utilization, every physical node is allocated multiple virtual nodes (typically 256 v-nodes per host) distributed uniformly across the 32-bit hash space using MD5 / Murmur3 hash functions.

Failure Domain Pinning

Rokka's placement algorithm enforces strict physical isolation rules:

  • Rack Diversity: Primary data chunks and their corresponding Cauchy parity stripes are mathematically prevented from residing on the same rack or power circuit.
  • Datacenter / Region Pinning: For multi-datacenter clusters, tenant policies can pin chunks to specific sovereign legal jurisdictions.

3. Storage Node Lifecycle States

Storage nodes in Rokka transition through deterministic lifecycle states managed via the Raft coordinator:

State Write Eligibility Read Eligibility Description
Active (Online) Yes Yes Fully operational node receiving writes and serving reads.
Maintenance No Yes Temporarily paused for planned maintenance (OS patching, RAM upgrade).
Draining No Yes Actively migrating resident chunks to other healthy cluster nodes prior to decommissioning.
Quarantined No Read-Only / None Automatically isolated by Abodi following predictive drive failure detection.
Evicted No No Permanently removed from the hash ring.