Building a Redis Server in Rust Reveals Concurrency Challenges

The author built a Redis-compatible server in Rust to understand the performance challenges of concurrency. They found that shared state contention, lock management, and observability were the real bottlenecks, not parsing or networking.

Details

The author built 'RustRedis', a Redis-compatible server in Rust, to understand where performance breaks under concurrency. The server follows a task-per-connection model, with each connection parsing the RESP protocol, executing commands, and returning responses. Two implementations were tested - one with a global mutex lock, and one with a sharded lock using DashMap. At low load, everything worked fine, but at high load, the bottleneck was shared state contention, not parsing or networking. The global mutex lock caused a 'lock convoy effect' where all writes serialized and throughput collapsed. Replacing the global lock with sharded locks using DashMap reduced contention and improved throughput by ~60% and latency by ~40% at high concurrency. However, the sharded approach had more overhead per operation. Observability also became an unexpected bottleneck, as tracking metrics per command introduced another shared structure that caused ~30% performance drop. The author also explored persistence trade-offs, finding that 'always' mode (fsync every write) caused an ~80% throughput drop, while 'every second' had minimal overhead. The key insight is that performance is not about code speed, but about contention management.