Redis-Lite 🚀

Welcome to Redis-Lite, a high-performance, concurrent, in-memory key-value database written in modern C++ from scratch. It is designed to mimic the core mechanics of Redis while adding 100% durable Write-Ahead Logging (WAL), an O(1) LRU caching algorithm, and strict thread-safety under heavy concurrent load.

Caution

Why you shouldn't expose this to the internet: While Redis-Lite implements basic password authentication, payload limits, and memory bounds, it is fundamentally a local development and systems-engineering project. It has not been professionally audited for buffer overflows, timing attacks, or advanced protocol exploitation. Always keep it safely bound to 127.0.0.1 or locked behind a strict Docker firewall.

Core Architecture & Engineering Highlights

Redis-Lite was built to solve complex systems-engineering challenges:

• O(1) LRU Cache Eviction: Functions exactly like Redis allkeys-lru. When the memory limit is reached, a background eviction loop gracefully pops the least recently used keys to make room. This is achieved via a highly-optimized dual-lock concurrency architecture (std::unordered_map paired with a doubly-linked std::list).
• High-Concurrency Thread Pool: Client connections are handed off to a fixed-size worker pool utilizing condition variables. Multiple clients can execute GET requests concurrently via std::shared_mutex (Reader-Writer locks) without blocking each other.
• Durable Write-Ahead Logging (WAL): Every mutating command is flushed to disk via POSIX fsync before the RAM map is updated. If the server crashes or loses power, your entire dataset is deterministically rebuilt on the next boot from the log.
• Robust TCP Wire Protocol: Does not rely on naive socket reads. It uses a strict, length-prefixed byte-stream framing protocol (similar to RESP). This prevents stream desynchronization, handles partial TCP packet fragmentation seamlessly, and blocks injection attacks.
• Secure Containerization: Runs on a minimal Alpine Linux Docker image as a fully restricted non-root user, enforcing memory/PID limits to prevent OOM DoS attacks.

Benchmarks & Testing

I stress-tested the server locally using custom Python benchmarking scripts (benchmark.py and test_lru.py) that strictly adhere to the internal TCP wire protocol. The test suite validates in-place overwrites, oversized payload rejections, and LRU eviction dynamics.

Benchmark: 10,000 asynchronous concurrent requests (50 worker threads) Note: Because Redis-Lite executes a physical fsync flush to the disk for every single write operation to ensure maximum durability, the throughput is completely bound by the underlying SSD IOPS limit.

Native Windows Build:

Execution time : 2.74 seconds
Total ops      : 10,000
Successful     : 10,000
Throughput     : ~3,638 ops/sec
Avg Latency    : 3.13 ms

Docker Container (WSL2 Virtual Filesystem): (Note: Docker's virtual filesystem bridge significantly limits heavy disk sync operations).

Execution time : 11.12 seconds
Total ops      : 10,000
Successful     : 10,000
Throughput     : ~899 ops/sec
Avg Latency    : 12.63 ms

Running It Yourself

1. Natively (CMake)

cmake -B build -DCMAKE_BUILD_TYPE=Release .
cmake --build build
$env:REDISLITE_PASSWORD="your_password_here"
./build/redislite.exe

2. Via Docker

You can pass the password directly as an environment variable when starting the container:

# In PowerShell:
$env:REDISLITE_PASSWORD="your_password_here"; docker compose up --build -d

# Or in Linux/Mac (Bash):
REDISLITE_PASSWORD="your_password_here" docker compose up --build -d

3. Run the Tests

Once the server is running (natively or in Docker), you can validate the LRU behavior or benchmark the raw throughput:

$env:REDISLITE_PASSWORD="your_password_here"
python test_lru.py
python benchmark.py