Aarkam / Aarkam Wiki / Architecture / Distributed Ecosystem & System Topology
Core Architecture Architecture

Distributed Ecosystem & System Topology

Overview of the 4-module architecture powering Aarkam Sovereign Data Fabric.

Last updated: Sep 23, 2026

Aarkam System V2 is engineered from first principles as a 4-tier modular sovereign storage fabric. Unlike monolithic legacy storage appliances or public cloud object stores that couple storage, tenant management, and diagnostics into brittle monoliths, Aarkam decouples each tier into an independently scalable and deployable subsystem.


The Four System Modules

┌────────────────────────────────────────────────────────────────────────┐
│                        1. Aarkam.IO Control Tower                      │
│        (Multi-Tenant UI Portal, API Gateway, S3 Gateway Backbone)       │
│                           Ports: 7771 / 57771                          │
└───────────────────────────────────┬────────────────────────────────────┘
                                    │ gRPC mTLS Control Path
                                    ▼
┌────────────────────────────────────────────────────────────────────────┐
│                        2. Rokka.Coordinator                            │
│           (Stateless Control Plane, Raft MON Consensus Quorum)         │
│                           Ports: 7774 / 57774                          │
└───────────────────────────────────┬────────────────────────────────────┘
                                    │ Hash Ring Placement
                                    ▼
┌────────────────────────────────────────────────────────────────────────┐
│                        3. Rokka.StorageNode                            │
│            (Data Plane Daemon embedding Kdouja LSM Engine)             │
│                           Ports: 7775 / 57775                          │
└───────────────────────────────────┬────────────────────────────────────┘
                                    │ In-Process Direct I/O
                                    ▼
┌────────────────────────────────────────────────────────────────────────┐
│                        4. Abodi Diagnostics Sidecar                    │
│          (Continuous Hardware Telemetry & Machine Learning Scoring)    │
│                           Ports: 7776 / 57776                          │
└────────────────────────────────────────────────────────────────────────┘
Module Role Deployment Target Protocol
Aarkam.IO Multi-tenant Web Management Portal & Gateway Backbone Management Nodes / DMZ Edge HTTPS, gRPC
Rokka.Coordinator Stateless Control Plane, Raft MON Quorum, Consistent Hash Ring 3+ Coordinator Nodes gRPC over HTTP/2
Rokka.StorageNode Data Plane streaming daemon embedding Kdouja.Engine Physical Storage Hosts gRPC over HTTP/2, Direct NVMe I/O
Abodi Autonomous S.M.A.R.T. health sidecar & ML predictive engine Sidecar on every Storage Host Local IPC (WMI/sysfs), gRPC

Interaction Flow & End-to-End Write Path

When an enterprise client, SDK, or AWS CLI uploads an object into Aarkam:

  1. Client Ingestion: Client sends an S3 PutObject or REST request to Aarkam.IO.
  2. Placement Resolution: Aarkam.IO queries Rokka.Coordinator over internal mTLS to resolve the active Consistent Hash Ring topology.
  3. Client-Side Envelope Encryption: Before any chunk traverses the internal network, Aarkam.IO (utilizing Kdouja.Primitives) generates an ephemeral per-object Data Encryption Key (DEK), encrypts the payload with AES-256-GCM, and divides it into 4KB chunks.
  4. Cauchy Reed-Solomon Erasure Coding: If writing to an erasure-coded pool (e.g., Ahmodi 8+3 Profile), the matrix generates parity chunks using SIMD AVX-512 vector acceleration.
  5. Parallel Direct I/O Streaming: Chunks are streamed concurrently to the assigned Rokka.StorageNode daemons.
  6. LSM Durability: Each Rokka.StorageNode hands its chunk to the embedded Kdouja.Engine, appending to the Write-Ahead Log (WAL) and memory skip-list before acknowledging durability.
sequenceDiagram
    autonumber
    actor Client as S3 Client / Application
    participant AIO as Aarkam.IO (Web Portal / Gateway)
    participant RCO as Rokka.Coordinator (Raft MON)
    participant SNA as Storage Node A (Kdouja)
    participant SNB as Storage Node B (Kdouja)
    participant ABA as Abodi Sidecar

    Client->>AIO: PutObject("vault-ledger.enc")
    AIO->>RCO: Query Placement & Hash Ring Topology
    RCO-->>AIO: Return Target Node Allocations (Node A, Node B)
    Note over AIO: AES-256-GCM Envelope Encryption<br/>Split into 4KB Chunks + Ahmodi Parity
    par Parallel Chunk Streaming
        AIO->>SNA: Stream Chunk 0..N (gRPC mTLS)
        AIO->>SNB: Stream Chunk Parity (gRPC mTLS)
    end
    SNA->>SNA: Kdouja WAL Direct Write & MemTable
    SNB->>SNB: Kdouja WAL Direct Write & MemTable
    SNA-->>AIO: Acknowledge Durable Write
    SNB-->>AIO: Acknowledge Durable Write
    AIO-->>Client: 200 OK (ETag, Signature Confirmed)
    ABA-.->SNA: Background SMART & IOPS Telemetry

Architectural Isolation Guarantees

  • No Cross-Tier Contamination: A firmware upgrade or disk failure on a storage node never impacts the control plane or web portal.
  • Zero-Allocation Data Paths: Chunks pass through pooled memory spans (ReadOnlySpan<byte>), preventing garbage collector spikes under high concurrent load.
  • Deterministic Blast Radius: Node outages are isolated to their specific hash-ring partitions, and missing chunks are regenerated immediately on surviving nodes.