Hey everyone, I’m Yasir. I’m an 18-year-old software engineering student from Pakistan, and for the last few months, I’ve been going down a very deep, very complex rabbit hole: Systems Programming in Rust.
When I started learning about distributed systems, I noticed a recurring theme: tools like Apache Kafka and Redis are absolute industry standards, but they come with a catch. Kafka relies heavily on the JVM (hello, GC pauses and massive memory footprints), and standard in-memory stores often hit bottlenecks when scaling across modern multi-core CPUs due to OS-level thread contention and locks.
I didn't have the budget to run massive AWS clusters for my personal projects. I needed something that could run on a potato but still handle enterprise-level throughput.
So, I decided to build my own.
Enter Velocity-Suite (Velocity-MQ & VelocityDB)
I built two core **infrastructure pieces entirely from scratch in Rust:
Velocity-MQ: A zero-GC, lock-free message queue (Kafka alternative).
**VelocityDB: A thread-per-core, lock-free in-memory store (Redis alternative).
My goal wasn't just to write another wrapper. I wanted to bypass traditional OS bottlenecks entirely. Here is the architecture that made it happen:
1_. Bypassing the Kernel with io_uring
Traditional synchronous I/O or even epoll wasn't cutting it for the persistent disk I/O I wanted. I integrated Linux io_uring for asynchronous I/O. By using O_DIRECT, the system completely bypasses the OS page cache. This means zero-copy transfers straight from the disk to the application memory, resulting in microsecond latencies._
2. Thread-per-Core Architecture
Instead of having multiple threads fighting over a shared state (and melting the CPU with context switches), I used a thread-per-core model. Each thread owns its data. No locks, no mutexes blocking the hot path.
3. Lock-Free Concurrency
To allow threads to communicate without slowing down, I heavily utilized lock-free data structures (like ring buffers) and atomic pointers. Fighting the Rust borrow checker while dealing with std::sync::atomic memory ordering (Acquire/Release semantics) was probably the hardest thing I’ve ever done, but the performance payoff was insane.
The Benchmarks 🚀
After weeks of debugging segmentation faults and memory ordering bugs, I finally ran the benchmarks on my local machine:
VelocityDB: **Reached **1.6M+ Requests Per Second (RPS). Click this : https://github.com/developer-yasir/velocitydb .
Velocity-MQ: Pushed 600k+ ops/sec with virtually zero garbage collection overhead. https://github.com/developer-yasir/Velocity-MQ
Running this on minimal RAM felt like a superpower.
Why I am sharing this (I need your help!)
I am incredibly proud of what I've built, but I am also just a 1st-semester CS student. I know for a fact that my code isn't perfect. Systems programming is brutal, and edge cases around memory barriers and crash recovery are terrifying.
I am putting this out here because I want to learn from the best.
If you are a senior Rustacean, a systems engineer, or just someone who loves high-performance backends, I would be honored if you could look at my code.
Roast my architecture.
Tell me where my memory ordering is flawed.
Open an issue if you see a bug.
You can check out the code here:
🔗 https://github.com/developer-yasir/

If you find this project interesting or helpful, dropping a ⭐ on the repo would mean the world to me and keep me motivated to keep building!
Let me know your thoughts in the comments. Let's talk about io_uring and Rust!