In a store that answers only by key, which index shape suits a lookup by exact value, and which suits 'the twenty most recent'?

## Start from the access path, not the data An application-maintained index is a second entry the application writes so it can look something up by a value. It is built for exactly one question, and the question decides the shape. Two questions cover almost every case seen in practice. - **"Which accounts have this value?"** — a membership question. The answer is a set of keys and their order does not matter. - **"Which twenty accounts are most recent?"** — a ranking question. The answer is a slice of an order, and which slice you want is part of the read. Getting these confused is the usual design error: a membership index cannot answer a ranked question without the caller reading all of it, and an ordered index used for membership pays for an ordering nobody reads. ## The two shapes | | Membership lookup | Ranked lookup | |---|---|---| | Index entry | one per distinct value | one per access path | | Value held | an unordered member collection of keys | a score-ordered collection of keys | | Write on create | add the key to the entry for its value | add the key with its score | | Write on change | remove from the old value's entry, add to the new | write the new score for the same key | | Growth driver | the count of distinct indexed values | the count of keys ever added | | Bound needed | none beyond entry size | trimming, or it grows without limit | A concrete membership index: `index:account-by-status:suspended` holding the keys of suspended accounts. A concrete ranked index: `index:account-by-last-seen` holding each account key with a numeric score derived from when it was last seen. Both key strings are conventions a team invented, not a product surface. ## What varies between stores, and why it matters here This is the part that decides whether either shape is available at all. - Where the server **understands the value as a collection and can read or write part of it**, adding one key to a membership index is one small operation against a large index, and a ranked index can hand back the slice you asked for without the caller reading the rest. - Where the server treats values as **opaque bytes it only hands back**, there is no partial change. Every add is read the whole value, decode it, insert, encode, write it back. That has three consequences: two concurrent writers can overwrite each other's change, the index is capped by how large one entry may grow, and the cost of one add rises with how much the index already holds. So the same design question has two honest answers depending on the store, and a candidate who states only one is describing the store they know. On an opaque-value store the workable pattern is one small entry per indexed value — `index:account-by-email:[email protected]` holding a single key — and an acceptance that the ranked access path is not expressible in the tier and belongs to the engine that owns the data. ## What each shape costs on every write Both shapes turn one logical write into several operations: 1. Creating the account writes the entry and adds to the index. 2. Changing the indexed value removes the key from the old value's index entry and adds it to the new one — two index operations, not one. 3. Deleting the account has to remove the key from the index as well. A ranked index adds a fourth obligation: something has to bound it. Nothing removes a key from an ordered index because it got old, so without a trim on write or a periodic pass it accumulates every key ever added, and it becomes one of the largest entries in the keyspace. A **lifetime attached to the index entry** does not solve this either — it removes the whole index, not the stale members inside it. ## The shape that should make you stop When a design needs several values combined — "suspended accounts in this region, most recent first" — each combination is another index to write, another to repair, and the write amplification multiplies. That is the point at which an application-maintained index has stopped being a shortcut. Either a deployment has an **optional indexing add-on** that maintains value-level lookups server-side, in which case the store owns the correctness and you own its operational surface, or the question belongs to a system whose job is answering questions about values rather than returning what you named.