Free to read

Build your own Redis in Rust, one short crate 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. Idiomatic async Rust on tokio. No frameworks. 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 Rust, one short cargo crate 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. The Rust idioms (tokio tasks, enum sum types, Arc with a Mutex, broadcast channels) replace threads and locks from other languages while the architecture stays the same.

Write your own Redis in Rust on tokio, one short crate at a time. Sockets, the wire language, the store, expiry, persistence, fan-out, and a backup machine.

What you'll ship

Real projects, not toy demos.

  • A tokio TCP server using TcpListener and tokio::spawn per connection
  • A RESP parser built on a typed enum sum type with recursive array decoding
  • A KV store using Arc<Mutex<HashMap>> with a dispatch match expression
  • EXPIRE / TTL / PERSIST with Instant-based TTLs and lazy delete
  • AOF persistence using tokio::fs and the Option<&AofFile> pattern for replay
  • RDB snapshots via tokio::fs::write to tmp plus atomic tokio::fs::rename
  • SUBSCRIBE / PUBLISH using tokio::sync::broadcast and the select! reader/writer pattern
  • Master/replica replication via a broadcast feed and a SYNC bootstrap phase
  • Graceful shutdown via tokio::signal::ctrl_c, a watch channel, and a Semaphore-based drain
  • A benchmark harness that compares your Rust server to real Redis on p50/p95/p99

What you'll learn

You finish able to:

  • Build a concurrent tokio TCP server using TcpListener and per-connection spawn
  • Parse the Redis wire format with an enum sum type and a recursive decoder
  • Choose between Arc<Mutex<T>>, Arc<RwLock<T>>, and dashmap based on access pattern
  • Implement TTLs and AOF-replay-safe persistence with Instant and tokio::fs
  • Snapshot in-memory state under a lock and write it atomically with tokio::fs::rename
  • Wire pub/sub and replication using tokio::sync::broadcast and the select! reader/writer pattern
  • Coordinate graceful shutdown with tokio::signal, watch channels, and Semaphore drain

Curriculum

From TcpListener to your own Redis.

  1. 01

    Network and protocol

    Open a TCP port with TcpListener, spawn a task per connection, parse RESP with an enum sum type.

  2. 02

    Store and expiry

    Arc<Mutex<HashMap>> around the store, then Instant-based TTLs with lazy delete.

  3. 03

    Durability: AOF and RDB in Rust

    tokio::fs append-only file with the Option<&AofFile> pattern, then RDB snapshots that clone under the lock because Rust has no fork.

  4. 04

    Messaging and replication

    broadcast channels for pub/sub, then the same broadcast feed for master/replica log shipping.

  5. 05

    Scaling: Graceful shutdown and benchmark

    tokio::signal + a watch channel for fan-out cancellation + Semaphore for drain bookkeeping. Then measure your server.

Who it's for

Is this for you?

Rust developers

You write Rust services. You want a project that exercises tokio, Arc, Mutex, enum sum types, and lifetimes in one cohesive build.

Backend engineers exploring Rust

You know another language. You want to see Rust idioms in a system that actually has hard requirements (concurrency, persistence, networking) so the ownership story clicks.

Engineers building Redis clients

You wrote a Redis client and 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.

  • How does it compare to the Python, Go, and Node 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>>. The course README compares all four side by side.

  • Will my Rust server beat real Redis?

    No, but it closes most of the gap. Real Redis is hand-tuned C. Our Rust version typically lands 1.5-2x slower on the bench, depending on workload. The capstone explains exactly where the remaining gap comes from.

  • What about async vs sync Rust?

    This course is async-first because tokio is the production choice for networked servers. The same architecture works with std::net + threads, but the exercises stay focused on the async story.