Aarkam / Aarkam Wiki / Architecture / Distributed Ecosystem & Six-Engine Architecture AARKAM-SPEC-0101
Unified Architecture (SAT & SCT) Six-Engine Fabric Architecture • AARKAM-SPEC-0101

Distributed Ecosystem & Six-Engine Architecture

Comprehensive architectural blueprint of the six decoupled engines powering Aarkam Sovereign Data Fabric: Aarkam.IO, Rokka, Kdouja, Abodi, Ahmodi, and AM CLI.

Last updated: Nov 03, 2026 Classification: Sovereign Tier-4 Enterprise
Document Identifier AARKAM-SPEC-0101
Standard Status
Normative Spec
Security Classification Sovereign Tier-4 Enterprise
Specification Revision V-1.0.0-GA • 6 min read

Aarkam System V2 is engineered from first principles as a six-engine decoupled sovereign storage fabric. Unlike monolithic legacy storage appliances or public cloud object stores that bind storage, consensus, encryption, and diagnostics into brittle runtimes, Aarkam decomposes the storage stack into six independently scalable, deployable, and testable subsystems.


The Six Decoupled System Modules

❖ Aarkam Sovereign Storage Fabric — Six-Engine Architecture
Zero-Allocation gRPC mTLS Mesh
MODULE 1 Aarkam.IO Control Tower & Edge Gateway

Multi-Tenant UI Portal • Sovereign Identity & IAM • S3 REST SigV4 Gateway Backbone • WORM Object Lock

Web: 7771/57771 • S3: 7772/57772
▼ gRPC mTLS Placement & Topology Resolution
MODULE 2 Rokka Distributed Control Plane & Fabric

Stateless Raft MON Consensus Quorum • Consistent Hash Ring • StorageNode Streaming Daemons

Coord: 57774 • Node: 57775
▼ Direct In-Process Storage Execution
MODULE 3 Kdouja Direct I/O Embedded Storage Core

Segment-Consolidated PageStore (256MB Segments) • Zero Inode Exhaustion • Direct NVMe Bypass • Arena Skip-List

In-Process Engine
▼ Mathematical Parity Kernel & Hardware Acceleration
MODULE 4 Ahmodi Cauchy Reed-Solomon Erasure Coding

SIMD AVX2 / AVX-512 Galois Field GF(2⁸) Kernel • 58.3% TCO Hardware Savings • Speculative Hedged Reads

12.5 GB/s / Core
▼ Out-of-Band Hardware Telemetry & Self-Healing
MODULE 5 Abodi Autonomous Telemetry & Predictive Sidecar

Kernel S.M.A.R.T. Telemetry • NVMe Wear Tracking • ML Failure Runway Forecasting • Zero-Downtime Eviction

Ports: 7776 / 57776
▼ Unified Fabric Control & Day-2 Operations
MODULE 6 Aarkam.AM Unified Interactive Operator CLI (`am`)

Single-Binary Orchestration • 27 Management Domains • POSIX Exit Codes • Structured JSON/YAML & Live Watch

Binary CLI (`am.exe`)

System Modules Cross-Reference Specification

Module Primary Responsibility Deployment Target Network / Protocol Default Ports
Aarkam.IO Multi-tenant Web Portal, S3 REST Gateway, IAM, Sovereign Policy Management Nodes / DMZ Edge HTTPS, gRPC mTLS Web UI: 7771 / 57771
S3 Gateway: 7772 / 57772
Rokka Distributed Fabric, Raft MON Quorum, Consistent Hash Ring, Data Streaming 3+ Coordinator Nodes & all Storage Hosts gRPC over HTTP/2 with mTLS Coordinator: 7774 / 57774
StorageNode: 7775 / 57775
Kdouja Direct I/O Chunk Persistence, Segment PageStore, In-memory Skip-List In-process inside Rokka.StorageNode In-process memory spans, Direct NVMe I/O Embedded Native Core
Ahmodi Cauchy Reed-Solomon Erasure Coding, AVX-512 SIMD Galois Field Kernel Shared Library in Gateway & Recovery Nodes SIMD Vector Registers / CPU Bus In-Process Vector Kernel
Abodi Autonomous S.M.A.R.T. Telemetry, Machine Learning Wear Prediction, Heartbeat Flow Sidecar on every physical storage node Local IPC (WMI/sysfs), gRPC telemetry Sidecar: 7776 / 57776
AM CLI Single-binary cluster administration, 27 operator domains, rolling upgrades Operator workstations, Bastion hosts, CI/CD runners gRPC mTLS to Coordinator & StorageNodes Client Binary (outbound)

End-to-End Zero-Allocation Write Path

When an enterprise client or AWS S3 SDK writes an object into the platform, all six engines coordinate deterministically:

  1. S3 Ingest & Authentication (Aarkam.IO / Gateway): Client transmits an S3 PutObject request over TLS 1.3 to port 57772 (or 57771). Aarkam.IO verifies the AWS SigV4 HMAC-SHA256 signature in constant time using CryptographicOperations.FixedTimeEquals.
  2. Topology Resolution (Rokka.Coordinator): Aarkam.IO queries the active Raft MON leader over gRPC mTLS to resolve the current Consistent Hash Ring topology epoch and target storage nodes.
  3. Client-Side Envelope Encryption (Aarkam.IO): A random 256-bit Data Encryption Key (DEK) is generated per object, wrapped via customer-owned HSM (PKCS#11 / KMIP), and payload chunks are encrypted with AES-256-GCM.
  4. Cauchy Erasure Coding (Ahmodi): The encrypted bitstream is divided into $K$ data chunks. Ahmodi's AVX-512 vector kernel computes $M$ Cauchy parity chunks (e.g. 8+3 standard profile) at over 12.5 GB/s per core.
  5. Parallel Network Streaming (Rokka): Chunks stream concurrently across internal gRPC mTLS channels directly to target Rokka.StorageNode instances.
  6. Direct I/O Persistence (Kdouja): Each storage node passes chunks to its embedded Kdouja.Engine, which executes unbuffered Direct I/O (O_DIRECT) into pre-allocated 256MB segment containers, appending to the WAL and arena skip-list.
  7. Autonomous Health Supervision (Abodi): Concurrently, Abodi evaluates physical drive S.M.A.R.T. counters and I/O latency jitter, feeding health scores into Rokka's consensus ring.

Architectural Isolation Guarantees

  • Decoupled Control & Data Planes: Storage coordinator failure never halts active chunk read/write operations. Storage nodes continue serving cached hash ring epochs.
  • Zero Inode Exhaustion: Kdouja packs billions of 4KB chunks into 256MB segment containers, reducing filesystem entries by 99.999% and eliminating operating system directory lock contention.
  • Zero Memory Allocation on Hot Paths: All chunk transfers utilize ReadOnlySpan<byte> and pooled unmanaged memory buffers, eliminating .NET Garbage Collection pauses.
  • Autonomous Pre-Failure Evacuation: Abodi identifies failing hardware up to 72 hours before catastrophic failure, triggering proactive Cauchy RS migrations without emergency reconstruction storms.