Key-Value Store

Overview

A small storage engine built to interoperate with Redis clients while staying small enough to reason about under concurrency.

Challenge

Interoperating with Redis clients while keeping the storage engine small enough to reason about under concurrency: it must speak RESP2 as a fallback for clients that do not negotiate RESP3, must cap concurrent work, and must distribute keys across shards deterministically.

Responsibilities

• Implemented the RESP2/RESP3 encoder and decoder.
• Built the TCP server, command dispatcher, and graceful shutdown.
• Added sharding with a consistent-hash ring and a bounded worker pool.
• Wrote a bundled CLI client that reuses the same client library.

Solution

Speak the Redis protocol well enough for existing clients, then keep the storage path bounded and predictable under concurrent load.

Architecture

Go. internal/resp codec, internal/server (TCP listener, handler, worker pool), internal/store (thread-safe shards and consistent-hash ring), cmd/kvs-cli client.

Technical decisions and trade-offs

• Implemented RESP3 with automatic fallback to RESP2 behind a HELLO negotiation, so modern clients get richer types without breaking older ones.
• Distributed keys with a consistent-hash ring rather than modulo hashing, so adding a shard remaps only a fraction of keys.
• Bounded concurrency with a fixed worker pool instead of one goroutine per connection, trading some throughput for predictable memory use.

Outcomes

• PING, SET, GET, DEL, INCR, and HELLO implemented and documented in the README with a runnable server and CLI.
• Server flags for port, shard count, and worker count.

Technologies

• Go