Key-value Store

For a long time there was one place to put data. The relational database, which stores rows and columns in tables and links tables to each other, was the default for business systems, and member records and order records alike went into it.

Problems started when work of very different shapes shared that one place. Pagedeck's document list screen had to check, every time it opened, whether the person making the request was still logged in. The answer is always short — look up one key, get back one identity. But fetching that one line meant knocking on the relational database every time, and as users grew, that lookup accounted for most of the traffic.

When Theo dug in, the issue turned out to be the procedure rather than the volume. A relational database parses the query, plans which tables to read in which order, and only then produces the answer. That planning is worth every cycle for a complicated question. For a question where you already hold the key, most of it is overhead.

A key-value store is what you get when that overhead is removed. It accepts exactly one question — give me the value hanging on this key — and answers it very quickly. Everything a general-purpose database does beyond that — joining tables, filtering by arbitrary conditions, enforcing a schema — is given up on purpose.

It makes lookups by a key you already hold cheap. A single-row lookup that costs a few milliseconds in a relational database usually finishes under one millisecond here. Both feel instant to a person, but when one screen makes twenty such lookups and the screen opens hundreds of times a second, the difference shows up as headroom across the whole service.

Three things account for the speed.

1. There's only one way to look something up. The key is computed into the location of the value directly, with no conditions to interpret and no index to walk.
2. The data usually lives in memory. Never touching disk is physically faster. The tradeoff is that a restart can wipe it, so only things that can afford to disappear go in.
3. Each value can carry an expiry. Set it to delete itself in thirty minutes and you never write the code that cleans up stale entries.

So what goes in is fairly predictable.

• Login state. The session, the state a server keeps to remember a user, lives here. Scale to three servers and all three read the same store, so whichever one takes the request sees the same person.
• Caching, storing a result once so it can be reused. A heavy analytics screen gets its result parked here for five minutes.
• Numbers that need counting. Values that move constantly, like how many requests one user made in the last minute, are lighter to handle here than in a table. Most key-value stores can increment a counter in one operation, so two requests arriving at the same instant don't overwrite each other's result.

Choosing comes down to a single question: do you already know the key when you go looking?

1. A relational database. Data in tables and relations, queried by conditions written in SQL. If you need to find last month's signups who never paid — a condition rather than a key — this is the one. Anything involving money also stays here, because it needs transactions, which bundle several operations so they all succeed or all get undone.
2. A document store from the NoSQL family, which isn't bound to a fixed table shape. Records can hold different fields, and you can search by fields inside the value. It takes the middle position when the structure changes often but you can't give up conditional search.
3. The application's own memory. On a single server this is the fastest option and requires installing nothing. Add a second server and each one holds its own copy, which shows up as a setting that flips back and forth depending on which machine answers.

These aren't competitors. Most services keep the source of truth in a relational database and put a key-value layer in front of it. Plenty of teams run four kinds at once, adding something like a vector database to handle a question none of the others can answer.

"Stop recomputing this dashboard. Park it in the key-value store for five minutes."

The same answer is being calculated repeatedly, so store it and reuse it.

"Don't put that there. We're going to need it by company later."

The data will eventually be looked up by a condition rather than a key.

"Logins keep dropping since we added servers. Sessions have to move out of the app."

Each server holds its own state, so move it to a shared store.

Sessions were the first thing Pagedeck moved. The week a second server went up, tickets came in about people getting logged out at random. Sofia collected them, passed them along, and the cause was obvious once seen: the two servers were each keeping login state in their own memory.

The admin analytics screen came next. It ran a heavy query stitching six tables together, and Mia opened it several times a day. Caching the result for five minutes took the screen from two seconds to a tenth of one. In exchange, Mia accepted that a team signing up just now won't appear in the list immediately. That trade comes attached every time something gets cached.

The most common move after seeing the speed is wanting to relocate the source of truth. Lookups get tens of times faster, so why not keep member records here too? Because this store can't find anything without a key. It will hand back a member by member ID, but it has no way to answer a request for everyone who signed up last month — and that request always eventually arrives. Discovering this after the move means migrating accumulated data back.

The other one is treating "it's in memory" as "losing it is fine" across the board. True for a cache, but park something irreplaceable there — a checkout in progress, say — and one restart takes it. The dividing line is whether the value can be recomputed. Anything that can't belongs in a store that writes to disk. Some key-value stores do offer durable modes that survive a restart, which is worth knowing about, but reaching for one is a decision to make deliberately rather than something to assume is already on.