Free to read

Build your own Redis in Ruby, one short server.rb at a time

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.

Start readingPreview curriculum

Still deciding? Ask first.

Message a mentor about fit, prerequisites, or where to start. Replies come on WhatsApp, usually within a day.

  • Curriculum fit, prerequisites, or where to start
  • Honest answer, no pressure to enroll

Taught by an engineer who has shipped this

  • ISO 27001

    Led the engineering work behind the certification of a regulated EU platform.

  • Series A platform

    Architected the case-management product that became the business a €11.6M round was raised on.

  • 3x faster deploys

    Cut time-to-deploy by migrating to Kubernetes on GCP with deploy-on-merge.

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

Real projects, not toy demos.

  • A TCP server using TCPServer.accept + Thread.new per connection
  • A RESP parser using byteslice and tagged-array sum types in a recursive function
  • A KV store backed by a Hash and a single Mutex
  • EXPIRE / TTL / PERSIST with Time.now.to_f deadlines and lazy delete
  • AOF persistence using File.open("ab") with a serialising Mutex
  • JSON RDB snapshots with atomic File.rename
  • SUBSCRIBE / PUBLISH using one Queue per subscriber and a write-pump Thread
  • Master/replica replication that runs the same script with different ARGV
  • Graceful shutdown via Signal.trap("INT") plus ConditionVariable drain
  • A benchmark harness that compares your Ruby server to real Redis on p50/p95/p99

What you'll learn

You finish able to:

  • Build a concurrent TCP server with TCPServer and Thread.new per connection
  • Parse the Redis wire format using byteslice and tagged-array tuples
  • Coordinate shared state with Mutex.synchronize (and when the GIL is not enough)
  • Implement TTLs and AOF-replay-safe persistence with Time.now.to_f and File.open
  • Snapshot in-memory state under the lock and write it atomically with File.rename
  • Wire pub/sub and replication using one Queue per subscriber plus a write-pump Thread
  • Coordinate graceful shutdown with Signal.trap and ConditionVariable

Curriculum

From TCPServer to your own Redis.

  1. 01

    Network and protocol

    Open a TCP port with TCPServer, spawn a Thread per connection, parse RESP with byteslice.

  2. 02

    Store and expiry

    Hash + Mutex around the store, then Float-based TTLs with lazy delete.

  3. 03

    Durability: AOF and RDB in Ruby

    Append-only file with serialising Mutex, then JSON RDB snapshots with atomic rename.

  4. 04

    Messaging and replication

    Per-subscriber Queue with a write-pump Thread, then master/replica via the same script.

  5. 05

    Scaling: Graceful shutdown and benchmark

    Signal.trap + ConditionVariable to drain cleanly. Then measure your server against real Redis.

Who it's for

Is this for you?

Ruby developers

You write Ruby every day. You want a project that exercises socket, Thread, Mutex, File, Queue, and Signal.trap in one cohesive build.

Backend engineers exploring Ruby

You know another language. You want to see how Ruby idioms land in a system with hard requirements (concurrency, persistence, networking).

Sidekiq / Redis users

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

Common questions.

  • Do I need to know Redis internals already?

    No. Each step starts from scratch and adds one architectural idea. By the capstone you understand the full shape.

  • Does the GIL matter for this workshop?

    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.

  • How does it compare to the Python, Go, Node, Rust siblings?

    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.

  • Why no Fiber-based event loop?

    Step 9 uses Threads + ConditionVariable for graceful shutdown. The Fiber.schedule reactor pattern is covered in the exercises of steps 01 and 09.