Loading...
Loading...
Redis feels like a black box until you build a tiny version yourself. You start with a program that just listens on a port. By the end, the same program speaks the real Redis language, remembers data after a restart, and a backup machine quietly mirrors it. Pure standard library Ruby. No Rails. No gems. No magic.
Engineers are learning here from
Build your own Redis in Ruby, one short server.rb at a time. You will write a small server that listens on a port, then teach it the same language real Redis clients speak, then give it memory, then teach it to remember after a restart, then let many readers subscribe to one writer. By the end you will have a working stand-in for Redis you understand line by line. Pure standard library Ruby. The familiar Hash, Mutex, Thread, and Queue do all the work, no Rails and no gems.
Write your own Redis in Ruby, one short server.rb at a time. Sockets, the wire language, the store, expiry, persistence, fan-out, and a backup machine. Pure standard library.
What you'll ship
What you'll learn
Curriculum
Network and protocol
Open a TCP port with TCPServer, spawn a Thread per connection, parse RESP with byteslice.
Store and expiry
Hash + Mutex around the store, then Float-based TTLs with lazy delete.
Durability: AOF and RDB in Ruby
Append-only file with serialising Mutex, then JSON RDB snapshots with atomic rename.
Messaging and replication
Per-subscriber Queue with a write-pump Thread, then master/replica via the same script.
Scaling: Graceful shutdown and benchmark
Signal.trap + ConditionVariable to drain cleanly. Then measure your server against real Redis.
Who it's for
You write Ruby every day. You want a project that exercises socket, Thread, Mutex, File, Queue, and Signal.trap in one cohesive build.
You know another language. You want to see how Ruby idioms land in a system with hard requirements (concurrency, persistence, networking).
You use Redis through redis-rb every day. You want to know what the server is doing on the other side of every wire byte.
FAQ
No. Each step starts from scratch and adds one architectural idea. By the capstone you understand the full shape.
For IO-bound work (which a Redis-shaped server is), the GIL releases on syscalls, so threads remain effectively concurrent. The course covers the cases where Mutex is still needed even with the GIL.
Same architecture, different idioms. Python uses threads + GIL-protected dicts. Go uses goroutines + sync.RWMutex. Node uses the event loop + Map. Rust uses tokio tasks + Arc<Mutex<HashMap>>. Ruby uses Threads + Hash + Mutex, very close to Python.
Step 9 uses Threads + ConditionVariable for graceful shutdown. The Fiber.schedule reactor pattern is covered in the exercises of steps 01 and 09.
Write your own Redis in Ruby, one short server.rb at a time. Sockets, the wire language, the store, expiry, persistence, fan-out, and a backup machine. Pure standard library.