Key-Value Stores

A key points directly to a value

A Key-Value Store keeps pairs of “key → value.” The application knows the key and uses it to read, write, or delete the value. The model is simple, so this access can be made very fast and distributed effectively.

session:9f21 -> { userId: 42, expiresAt: ... }
feature:user:42 -> { darkMode: true }

The store itself usually does not need to understand the internal structure of the value as deeply as a relational database understands columns and relationships between tables.

The strength is a known access path

The key-value model is especially convenient when almost every request looks like “give me the value for this key.” Typical examples include sessions, settings, counters, temporary state, or fast lookup data.

If the application constantly needs filters across several fields, joins, and arbitrary analytical queries, key-only access becomes insufficient.

The key is part of the architecture

The key format influences data distribution and access convenience. It should be stable, unambiguous, and match how the application actually reads the data.

For example, if a profile is always read by userId, the user identifier is a natural key. If a required lookup uses another attribute, you may need a separate structure or a secondary index if the store supports one.

TTL is convenient for temporary data

Many key-value systems let you define a record lifetime. After the TTL expires, the value becomes unavailable and is removed according to the product's rules.

SET session:9f21 value TTL=30m

This is a natural fit for sessions, one-time tokens, and other data that should not live forever.