FlashDB – Technical Briefing Repo: https://github.com/moses-y/FlashDB (clone with git clone https://github.com/moses-y/FlashDB)

The Problem

Applications that need sub‑millisecond latency for simple GET/SET workloads must run many Redis instances or add a proxy layer, which increases operational complexity and limits CPU scaling.

What This Does

FlashDB implements the Redis RESP protocol with a lock‑free sharded hash map (crates/customhash). Core command handling lives in src/commends/*.rs (e.g., src/commends/string.rs::set, src/commends/hash.rs::hset). Persistence is provided via RDB snapshots (src/storage/rdb.rs). The Docker image (Dockerfile) packages the binary for quick deployment.

How It Is Wired

  1. Entry point – src/main.rs creates the listener and spawns a worker per CPU core (src/worker.rs::run_worker).
  2. Connection handling – each worker uses src/handler/conn.rs to read raw RESP bytes and forwards them to src/handler/dispatch.rs::dispatch.
  3. Command dispatch – dispatch matches the command name and calls the corresponding function in src/commends/*. The most‑used functions (by call‑graph) are store, write_wrong_args, set_str, is_empty, and write_integer.
  4. Data path – src/storage/hash.rs and src/storage/string.rs interact with the custom hash map (crates/customhash/src/lib.rs). The map’s API (new_value, free_value, capacity, drop) is invoked from 21 other files; the map holds 44 functions and 9 types, making it the primary blast‑radius module.
  5. Response encoding – src/utils/resp.rs provides write_ok, write_bulk, etc., used by virtually all command handlers (20‑plus calls).
  6. Expiration – src/storage/keys.rs::expire* and src/storage/value.rs::is_expired are called from 16 places each, ensuring stale keys are cleaned.
  7. Persistence – background saving is triggered from src/storage/rdb.rs via BGSAVE or a timed task (every 5 min). The only file I/O occurs here and in the initial load (src/storage/server.rs::load).

No external services are invoked; the repository touches the filesystem only for RDB snapshots.

How To Use It

# Build
cargo build --release

# Run locally
./target/release/flash_db   # listens on 0.0.0.0:8000 (hard‑coded in src/main.rs)

# Docker (image built from Dockerfile)
docker build -t flashdb .
docker run -p 8000:8000 flashdb

Configuration is minimal; the server reads flashdb.rdb from the current directory on start and writes to the same file on shutdown or BGSAVE. No additional env‑vars are defined in the repo.

Real‑World Use

A microservice that stores session tokens can replace a Redis instance by pointing its client to localhost:8000. Because reads are wait‑free and writes lock‑free, throughput scales with core count, making it suitable for high‑concurrency back‑ends where a single Redis node becomes a bottleneck.

Code Health & Issues

  • High – Pin third‑party GitHub Actions – .github/workflows/ci.yml uses tags (@v2, @v3). Replace each with a 40‑character commit SHA.
  • High – Add a LICENSE – no license file; legal reuse is blocked. Add MIT or Apache‑2.0.
  • Medium – Least‑privilege GITHUB_TOKEN – .github/workflows/ci.yml lacks a permissions block. Add permissions: contents: read.
  • Medium – Enable Dependabot – no dependabot.yml; add one for Cargo, Docker, and GitHub‑Actions.
  • Medium – Pin Docker base images – Dockerfile uses rust:alpine and alpine:latest. Replace with digests.
  • Medium – Add dependency‑vulnerability scan – no scan step in CI; integrate dependency-review-action or osv-scanner.
  • Medium – Set persist-credentials: false – checkout step keeps the token; add the flag and pass an explicit token only where needed.
  • Low – Job timeout – CI jobs lack timeout-minutes; set a reasonable bound (e.g., 20 min).

Additional observations: the codebase has deep nesting (max depth 8) in several core modules (src/storage/hash.rs, src/storage/string.rs, crates/customhash/src/lib.rs), duplicated 6‑line blocks across src/pubsub/frame.rs and src/utils/resp.rs, and an oversized crates/customhash/src/lib.rs (649 lines). Refactoring these areas would reduce cognitive load and improve maintainability.

The Bottom Line

FlashDB delivers a lock‑free, multi‑core‑scaled key‑value store with Redis‑compatible RESP handling and built‑in RDB persistence. The core architecture is sound, but the repository lacks a license, has several CI hygiene gaps, and contains deeply nested code that hinders rapid change. It is a strong candidate for workloads that need higher throughput than single‑threaded Redis, provided the team is comfortable addressing the identified maintainability and security concerns.