NoSQL · Data models beyond tables
What are key-value stores and what are their limits?
Short answer
A key-value store maps a key to an opaque value and offers very fast lookups by that key. It typically cannot query inside the value, so the application must design keys around every access pattern.
The model is deliberately small: put a value at a key, get it back, delete it. The store does not need to parse the value, which keeps the read path simple and fast. Redis, DynamoDB, etcd and Memcached are common examples with different durability and query features.
SET session:abc123 '{"userId":7}' EX 3600
GET session:abc123
DEL session:abc123
INCR counter:page:home
HSET user:7 name "Asha" plan "pro"
HGETALL user:7Designing keys
- Use a predictable namespace, such as user:7:profile or order:1042
- Include the query dimension in the key when the store cannot filter by value
- Avoid hot keys that concentrate traffic on one shard
- Set a TTL for cached or temporary data so stale entries expire without a cleanup job
The hard limit is query flexibility. If you need to find all sessions for a user, or all orders over a value, a pure key-value layout cannot do it efficiently. You either maintain a secondary index yourself or choose a store with indexes.
Follow-ups you should expect
Interviewers use these to check whether the first answer was understanding or memorisation.
- 1How would you query data by a non-key attribute?
- 2What is a hot key and how do you avoid it?
- 3When is a key-value store a bad system of record?
- 4How does DynamoDB extend the basic key-value model?
Say it in the interview
A key-value store is the simplest model: a key maps to a value, and the database does not inspect the value. That makes key lookups fast and horizontally scalable, but it also means every access pattern has to be encoded in the key or supported by an index. I namespace keys carefully, set TTLs for temporary data, and watch for hot keys. If the product needs flexible queries, I either choose a richer store or build the indexes explicitly.
Use this as a model, not a script. Saying it in your own words is what makes it survive follow-up pressure.
Related questions
Reading is step one
Now say it out loud.
Understanding an answer and delivering it under pressure are different skills. Rehearse this topic in a live NoSQL mock interview and get scored feedback on depth, clarity and confidence.