Key-Value Stores

Think about a dictionary. You know the word you're looking up, say, "ephemeral", and you go straight to the E section and find the definition. You don't scan every page from A to Z. You have the key (the word), and you get the value (the definition) in seconds.

Now imagine that dictionary has a billion entries, is distributed across 50 servers around the world, and can answer 10 million lookups per second.

That's a key-value store. And it's the backbone of almost every high-traffic system you've ever used.

Twitter uses key-value stores to cache your timeline. Amazon uses them for shopping cart sessions. Discord uses them for presence (who's online right now). Twitch uses them for live viewer counts. Every time you see data that loads instantly, before the page even finishes rendering, there's probably a key-value store behind it.

A key-value store has exactly one operation contract:

• PUT(key, value), store this value under this key
• GET(key), retrieve the value for this key
• DELETE(key), remove this key and its value

That's it. No schemas. No tables. No columns. No JOINs. No SQL. Just keys and values.

The key is a string. "user:42:session", "product:iphone-15:price", "rate-limit:192.168.1.1". You design your key naming convention to encode meaning.

The value can be almost anything, a string, a number, a JSON blob, a serialized object, or raw binary data. The store doesn't care what the value contains. It's just bytes.

The brutal limitation: you can only look up by key. Want to find all users in New York? Can't do it, unless "users-in-new-york" is a key. Want to sort products by price? Not possible. Key-value stores trade query flexibility for raw speed.