Key-value store

A key-value store is the simplest kind of database: every value sits under a unique key, and you read, write or delete it by that key. The store usually does not look inside the value, so it can be a string, a counter, JSON or a serialised object. That narrow interface is what makes key-value stores fast and easy to scale.

How it works

Most implementations sit on a hash map, which gives O(1) average lookups however many keys exist; some use sorted structures such as B-trees or LSM-trees so they can also scan key ranges. In-memory stores such as Redis keep data in RAM and add optional snapshots or an append-only file for persistence. Persistent stores such as etcd, which holds all Kubernetes cluster state, and Amazon DynamoDB write to disk and replicate across machines.

The One2N Go bootcamp exercise builds a small Redis in Go. SET name John returns OK and GET name returns "John". INCR counter on a missing key sets it to 1 and returns (integer) 1. DEL name returns (integer) 1 because one key was removed, and a second GET name returns (nil).

Why it matters in production

Key-value stores are the usual home for caches, sessions, rate limit counters, feature flags and configuration. The trade-off is that you can only ask by key: there are no joins, and any other query needs an index you maintain yourself. Plan for restarts, since an in-memory store without persistence comes back empty, and for hot keys, where one popular key puts all its load on a single node.