Key-Value Stores
The simplest NoSQL: get/put by key. Redis, Dynamo-style systems.
Level: intermediate
What is it?
A key-value store associates each key with a value and offers operations such as GET, PUT, and DELETE. Values may be opaque bytes, serialized objects, or structured data depending on the product.
Why does it matter?
Key-value stores provide a simple access pattern for caching, sessions, counters, and lookup-heavy workloads. They can offer high throughput, but query capabilities and transaction guarantees depend on the implementation.
Mental model
A key is the lookup handle; the value is retrieved without necessarily searching fields inside it. If the access pattern needs arbitrary predicates or joins, a relational or document model may fit better.
How it works
- Key distribution and partition strategy affect load balancing in distributed key-value systems.
- TTL and eviction policies can be central for cache workloads; persistent stores have different durability goals.
- Atomicity scope may be limited to one key or operation, or may be broader in particular databases.
- Serialization format and schema versioning still matter even when the server treats values as opaque.
- Cache misses, stale values, and invalidation are application-level correctness concerns.
Steps
- Choose a stable key that represents the lookup needed by the application.
- Serialize the value with an explicit schema/version where needed.
- Use GET/PUT/DELETE and define TTL, persistence, and consistency behavior.
- Handle cache misses, errors, and invalidation without assuming the value always exists.
Real-world usage
- Session stores, lookup tables, caches, and idempotency-key registries.
- Storing small values that are retrieved by known key.
Common mistakes
- Using ever-growing unbounded keys/values with no eviction or retention plan.
- Treating cached values as authoritative when invalidation is not reliable.
- Expecting relational joins or arbitrary filtering from a pure key-value access model.
Interview questions
When is a key-value store a natural fit?
When applications primarily retrieve or replace values by known key and do not need broad relational queries over value fields.
What makes cache invalidation difficult?
The application must keep cached copies aligned with changing source data across races, failures, TTLs, and multiple readers.