Key-value store
The simplest database shape: give it an exact key and get back the value stored under that key.
See it
What it is
A key-value store is a durable or in-memory map: give it one exact key and it returns the value stored there. The value may be a string, number, byte array, or serialized object, but the database does not need to understand its internal fields. Redis, Amazon DynamoDB, and RocksDB all offer this basic model with very different durability and distribution choices.
Reach for it when access already has a natural key: session token to session, feature name to setting, content hash to cached result. Exact lookups are simple and fast, and TTL support makes many stores useful for temporary data. If you need to filter arbitrary fields, join records, or ask ad hoc questions, another model will fit better.
Gotcha: the key design is the schema even when nobody calls it one. Keys must avoid collisions, distribute load, and be invalidated when their meaning changes. Expiration and eviction are different: a Redis key can vanish early under an eviction policy even if its TTL has not elapsed. Do not treat a cache-oriented key-value store as the only copy of data unless its persistence guarantees match that job.
Ask AI for it
Implement session storage in Redis using keys shaped as session:<sha256-token>, JSON values with userId and createdAt, and SET with EX 1800 and NX so every session expires and an existing token is never overwritten. Read with GET, revoke with DEL, refresh the TTL only after an authenticated request, and use MGET for bounded batch lookups. Configure an eviction policy explicitly, treat a missing key as a signed-out session, and add tests for expiration, collision, revocation, malformed JSON, and Redis unavailability.