🚀 Inside Orbit

🏗️ Core Architecture

Orbit Ledger uses the LMAX Disruptor pattern with a Ring Buffer for lock-free, high-throughput event processing. Here's the complete flow:

flowchart TD
    subgraph Input ["Step 1: Ingestion"]
        P1[User Thread]
        P2[API Thread]
        InputEvent>"Event: Credit ACC-001 $100"]
    end
    subgraph Memory ["Step 2: Orbit Core"]
        RB((ORBIT RING BUFFER))
        NoteRB["Ordered Sequence of Events
        1. ACC-001 (+100)
        2. ACC-002 (-50)
        3. ACC-001 (+20)"]
    end
    subgraph Workers ["Step 3: Parallel Workers (All Read Everything)"]
        direction TB
        
        subgraph W0 ["Worker 0 (CPU Core 1)"]
            Check0{"Hash % 2 == 0?"}
            Match0[ Process ACC-002]
            Ignore0[ Ignore ACC-001]
        end
        subgraph W1 ["Worker 1 (CPU Core 2)"]
            Check1{"Hash % 2 == 1?"}
            Match1[ Process ACC-001]
            Ignore1[ Ignore ACC-002]
        end
    end
    subgraph Batch ["Step 4: Batched Commit"]
        B0[Batch: ACC-002 Updates]
        B1[Batch: ACC-001 Updates]
    end
    P1 & P2 -->|Publish| RB
    RB -->|Sequence 1| W0 & W1
    RB -->|Sequence 2| W0 & W1
    RB -->|Sequence 3| W0 & W1
    W0 --> Check0
    Check0 -->|Yes| Match0
    Check0 -->|No| Ignore0
    W1 --> Check1
    Check1 -->|Yes| Match1
    Check1 -->|No| Ignore1
    Match0 --> B0
    Match1 --> B1
    style RB fill:#1a4d1a,stroke:#00d2ff,stroke-width:4px,color:#fff
    style Match0 fill:#1a3d4d,stroke:#00d2ff,color:#fff
    style Match1 fill:#1a3d4d,stroke:#00d2ff,color:#fff
    style Ignore0 fill:#4d1a1a,stroke:#ff6b6b,stroke-dasharray: 5 5,color:#fff
    style Ignore1 fill:#4d1a1a,stroke:#ff6b6b,stroke-dasharray: 5 5,color:#fff
    style B0 fill:#1a4d1a,stroke:#00d2ff,color:#fff
    style B1 fill:#1a4d1a,stroke:#00d2ff,color:#fff
                    

Processing Steps

Step 1: Ingestion

Multiple threads (API handlers, user requests) can publish events concurrently to the Ring Buffer. This is non-blocking and takes nanoseconds.

Step 2: Orbit Core (Ring Buffer)

Events are stored in a pre-allocated circular buffer. Each event gets a monotonically increasing sequence number, guaranteeing order.

Step 3: Parallel Workers

Workers process events in parallel using key sharding:

• Each worker reads all events from the Ring Buffer
• Workers only process events where hash(key) % threadCount == workerId
• This ensures each key is processed by exactly one worker (deterministic ordering)
• Different keys can be processed in parallel (high throughput)

Step 4: Batched Commit

When the release threshold is reached, all accumulated events for a key are committed as a single batch:

• 1 UPDATE for the final balance
• 1 batch INSERT for all history records

Key Concepts

⚡ Performance Modes

Orbit Ledger adapts to your hardware profile with two optimized performance modes:

📊 Orbit Internal Performance

The chart below isolates Orbit Ledger's throughput (ops/sec), demonstrating the engine's raw speed across various configurations. To ensure production-grade reliability, tests were conducted across multiple phases—including rigorous endurance runs of over 3,000,000 orders—validating both long-term stability and JVM efficiency. Key performance indicators from these tests are summarized below:

🆚 Comparison: Orbit vs Traditional DB

This table highlights the fundamental architectural differences that allow Orbit Ledger to achieve 500x-600x greater throughput than traditional RDBMS approaches.

Flow Comparison

sequenceDiagram
    participant T1 as Thread 1
    participant T2 as Thread 2
    participant DB as Database
    Note over T1, T2: Both update Account A
    T1->>DB: BEGIN TX & LOCK
    activate DB
    Note right of DB: ❌ Locked
    T2->>DB: BEGIN TX & LOCK
    Note right of T2: ❌  BLOCKED
    T1->>DB: UPDATE Balance
    T1->>DB: COMMIT
    deactivate DB
    Note right of DB: ✅ Released
    T2->>DB: Acquired Lock
    activate DB
    T2->>DB: UPDATE Balance
    T2->>DB: COMMIT
    deactivate DB
                            

sequenceDiagram
    participant T1 as Thread 1
    participant T2 as Thread 2
    participant RB as Orbit Engine
    participant DB as Database
    Note over T1, T2: Write to RAM
    T1->>RB: Credit $100
    T1-->>T1: ✅ Done (0 wait)
    T2->>RB: Debit $50
    T2-->>T2: ✅ Done (0 wait)
    Note over RB: Processing...
    RB->>RB: Memory +100
    RB->>RB: Memory -50
    Note over RB, DB: Batch Persist
    RB->>DB: ONE SAVE (+$50)
                            

DB Load Reduction (per 10,000 transactions)

💰 Cost Savings Example

E-commerce with 1M daily transactions

🔧 Under the Hood