Sekura Manager
RapidJSON + RocksDB = Lock-Free Execution
Platform: Apple M2 (8 GB RAM)
Compiler: Clang 18 (C++20, ARM64)
Libraries: folly, RocksDB 8.x, RapidJSON 1.1
1. Introduction
Most frameworks chase speed by inventing new data structures.
Sekura took the opposite path.
We simply use RapidJSON as our internal runtime data model —
not as a parser, not as a transport format,
but as the living memory structure that powers Sekura IDE, Sandbox, VOC, and VMS.
Sekura Manager builds on top of this model, combining
RapidJSON (data), RocksDB (state), and a lock-free event dispatcher (execution)
into one unified runtime core.
Formula: RapidJSON + RocksDB = Sekura::Core::Manager
2. Architecture of Sekura::Core::Manager
| Component | Role | Technology |
|---|---|---|
| RapidJSON | Internal runtime data model | C++20 + RapidJSON |
| RocksDB Layer | Persistent KV store and snapshots | RocksDB 8.x |
| Lock-Free Dispatcher | Event routing without mutexes | folly::MPMCQueue + cooperative yield |
Sekura::Core::Manager merges three levels of execution:
data (RapidJSON), persistence (RocksDB), and scheduling (lock-free loop).
It processes all events without global mutexes or context switches.
When data reuse is required, it cooperates with Sekura::Core::Storage,
which briefly locks objects to prevent redundant access —
without breaking the lock-free event cycle.
3. Benchmark Configuration
| Parameter | Value |
|---|---|
| Hardware | MacBook Air M2 (8 cores, 8 GB RAM) |
| OS | macOS 15.6 |
| Compiler | Clang 18 (C++20, ARM64) |
| Libraries | folly, RocksDB 8.x, RapidJSON 1.1 (Sekura allocator) |
| Method | google-benchmark |
| Environment | Isolated test session, no background tasks |
4. RapidJSON as Sekura’s Internal Runtime Model
RapidJSON serves as the native in-memory structure of Sekura Runtime.
Every Property, Layout, Algorithm, Stream, and Variant is represented as a RapidJSON node.
There is no conversion layer between IDE, Sandbox, VOC, and VMS —
they all work directly with the same live tree of RapidJSON objects.
This simple choice proved powerful.
Benchmarks show that RapidJSON’s raw speed is more than sufficient
for real-time operations in UI, simulation, and compilation contexts.
| Access Type | Example | Avg Time (ns) | Comment |
|---|---|---|---|
| Index const char* | value["3"] |
1010 | Direct index access, no copy |
| Index std::string | value[indexStr] |
1025 | Zero allocation overhead |
Key ["pos_x"] |
— | 849 | Flat key, top-level |
Key ["pos"]["x"] |
— | 1118 | Nested key lookup |
| GetIntRaw | — | 4.1 | Extracting integer |
| GetDoubleRaw | — | 5.6 | Extracting double |
| GetBoolRaw | — | 5.3 | Boolean value |
| GetStringRaw | — | 6.7 | Short strings, no allocation |
These results confirm that RapidJSON performs at microsecond-level latency
and nanosecond-level primitive access —
making it viable as Sekura’s core runtime data model, not just a parser.
5. Sekura::Core::Manager Performance
Sekura Manager implements a fully lock-free event dispatcher
based on folly::MPMCQueue with cooperative yielding.
5.1 Lock-Free Benchmark
| Writers | Workers | Throughput (ops/s) | Avg Latency (ms) | Drops |
|---|---|---|---|---|
| 1 | 1 | 41000 | 0.697 | 0 |
| 4 | 2 | 75000 | 0.379 | 0 |
| 8 | 4 | 131000 | 0.213 | 0 |
| 64 | 4 | 123000 | 0.247 | 0 |
| 128 | 4 | 125000 | 0.238 | 0 |
Peak throughput: 125,000 ops/sec
Average latency: 0.24 ms
Zero event loss.
5.2 PerfMT (Realistic Multithreaded Test)
| Threads | Processed | Time (ms) | Throughput (ops/s) | Avg Latency (ms) | Max (ms) | Drops |
|---|---|---|---|---|---|---|
| 1 | 1000000 | 5284 | 189251 | 0.00025 | 0.05 | 0 |
| 2 | 1000000 | 4415 | 226501 | 0.00027 | 0.17 | 0 |
| 4 | 1000000 | 4067 | 245881 | 0.069 | 0.63 | 0 |
| 8 | 1000000 | 4221 | 236911 | 0.025 | 0.63 | 0 |
| 16 | 837290 | 4164 | 201030 | 6.46 | 79.3 | 162710 |
| 32 | 783773 | 4132 | 189684 | 0.166 | 172.6 | 216227 |
| 64 | 562759 | 4143 | 135834 | 0.100 | 227.7 | 437241 |
Scaling remains nearly linear up to 8 threads.
Beyond that, cache saturation occurs — but stability is maintained.
RocksDB’s async writes show no measurable degradation.
6. Balanced Performance in Real Systems
Sekura Runtime never seeks “maximum throughput.”
It uses the power of Sekura::Core::Manager strategically —
allocating just enough performance for stability and predictability.
| Subsystem | Manager Type | Mode | Real Load |
|---|---|---|---|
| Sekura IDE | Async, single-threaded | Lock-free event loop | ~40,000 events/sec (UI-level) |
| Sekura Sandbox | Sync, single-threaded | Sequential | 1–2s startup spike, stable runtime |
| Sekura VOC | Sync | Direct-call | More time in sync than execution |
| Sekura VMS | Multithreaded | 1 Manager per CPU core | Scalable server execution |
Sekura deliberately avoids unnecessary parallelism.
Each subsystem operates at its optimal sufficiency point —
fast enough to feel instant, slow enough to remain deterministic.
This is the engineering embodiment of the Sekura Balance Code:
Speed in service of stability.
7. Conclusion
Sekura Manager is the heart of Sekura Runtime.
RapidJSON forms its data fabric,
RocksDB ensures persistence,
and the lock-free Manager keeps everything in motion — without conflict.
It powers all internal Jupiter Soft systems:
| Component | Purpose |
|---|---|
| Sekura IDE | Visual variant design and reactive UX |
| Sekura Sandbox | Safe runtime for live experiments |
| Sekura VOC | JIT compilation of variants |
| Sekura VMS | Master server for variant storage and monetization |
Together, these layers form a balanced, reactive architecture
where data, state, and execution coexist in harmony.
8. License & Attribution
© 2025 Jupiter Soft
Author: Akhat T. Kuangaliyev
Assisted by: ChatGPT (GPT-5)
Component: Sekura Manager
Citation: “Sekura Manager: RapidJSON + RocksDB = Lock-Free Execution (2025)”