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. Idiomatic async Rust on tokio. No frameworks. No magic.
Engineers are learning here from
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
What you'll learn
Curriculum
Network and protocol
Open a TCP port with TcpListener, spawn a task per connection, parse RESP with an enum sum type.
Store and expiry
Arc<Mutex<HashMap>> around the store, then Instant-based TTLs with lazy delete.
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.
Messaging and replication
broadcast channels for pub/sub, then the same broadcast feed for master/replica log shipping.
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
You write Rust services. You want a project that exercises tokio, Arc, Mutex, enum sum types, and lifetimes in one cohesive build.
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.
You wrote a Redis client and 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.
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.
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.
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.
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.