Build a Key-Value Store in Go

Goroutines, RWMutex, and zero dependencies — why Go is what Redis would use if it were built today

This is the Go companion to Issue 1: Build Your Own Redis in Python. Read that first for the 3-Question Framework, design pattern analysis, and interview strategy. This post focuses on the Go implementation and what changes when you leave Python behind.

---

Why Go for This?

In the Python version, we built a key-value store using a dict and FastAPI. It works, but it has a fundamental problem we explored in Issue 4: the GIL. Python threads cannot run in parallel on CPU work. Our background expiration thread blocks client requests.

Go has none of these problems:

• No GIL. Goroutines run on real OS threads across all CPU cores.

• Built-in concurrency. sync.RWMutex gives us concurrent reads with exclusive writes — exactly what a KV store needs.

• Static typing. The compiler catches type errors before runtime. No None surprises.

• Single binary. go build produces one binary. No virtualenv, no pip, no dependency hell.

This is why tools like Redis (if built today), etcd, CockroachDB, and Kubernetes are all written in Go.

---

Step 1: The Core Store

Python used a dict. Go uses a map — same O(1) hash map, but with explicit types.

package store

import (
	"sync"
	"time"
)

type entry struct {
	Value  string
	Expiry *time.Time // nil = no expiry
}

type KeyValueStore struct {
	mu   sync.RWMutex
	data map[string]entry
}

func New() *KeyValueStore {
	return &KeyValueStore{
		data: make(map[string]entry),
	}
}

What changed from Python:

The RWMutex is the big win. In Python, the GIL means only one thread runs at a time, regardless. In Go, RLock() allows unlimited concurrent readers, while Lock() (write) blocks everyone. This is exactly how production databases handle concurrent access.