Redis is often called a “data structure server.” It’s simple, fast, and surprisingly easy to understand at its core. I built a toy implementation to learn about networking protocols and in-memory data structures.

The Redis Protocol (RESP)

Redis uses a text-based protocol called RESP (REdis Serialization Protocol). It’s elegant in its simplicity:

  • +OK\r\n - Simple string
  • $5\r\nhello\r\n - Bulk string with length
  • *2\r\n$3\r\nGET\r\n$4\r\nkey\r\n - Array of bulk strings

Parsing this is straightforward—no complex binary formats to wrestle with.

Core Data Structures

My implementation supports:

Strings

enum Value {
    String(String),
    // ...
}

Simple key-value storage with GET, SET, and DEL commands.

Lists

Implemented as VecDeque<String> for efficient push/pop at both ends.

Sets

HashSet<String> for unique collections with SADD, SMEMBERS, etc.

Hashes

HashMap<String, String> for nested key-value pairs.

The Event Loop

Redis is single-threaded with an event loop. My version uses:

loop {
    // Accept new connections
    // Read from existing connections
    // Parse commands
    // Execute and respond
}

This simplicity is why Redis is so fast—no locking, no context switching.

Persistence

Real Redis has RDB snapshots and AOF logs. My toy version only does:

  • RDB-style: Serialize the entire database to a file periodically
  • No AOF (append-only file) for simplicity

What I Learned

  1. Protocol design matters: RESP is easy to parse and debug
  2. Single-threaded can scale: With async I/O, one thread handles thousands of connections
  3. Simplicity is a feature: Redis’s limited command set makes it predictable

Try It

$ cargo run
# In another terminal:
$ redis-cli -p 6379
127.0.0.1:6379> SET name "uvx"
OK
127.0.0.1:6379> GET name
"uvx"

It’s not production-ready (no replication, no clustering, limited commands), but it speaks enough Redis protocol to be useful for learning.