Questions: Key-Value Stores

Question 1

An application stores user profiles in PostgreSQL (200ms per query). A developer proposes caching results in Redis with a 5-minute TTL. A colleague objects: 'Key-value stores shouldn't hold data that's also in our relational database.' Who is correct?

• A. The colleague — key-value stores should never duplicate data from a relational database
• B. The developer — Redis should replace PostgreSQL for user profiles since it's faster
• C. The developer — using Redis as a cache layer in front of PostgreSQL is a common and appropriate pattern; TTL manages staleness
• D. Neither — the right solution is to optimize the SQL query itself

Answer: (C)

Using a key-value store as a cache layer in front of a relational database is one of the most common and appropriate architectural patterns in web systems. Redis (or Memcached) absorbs repeated read traffic at sub-millisecond latency, while PostgreSQL remains the durable source of truth for writes and complex queries. This is the complementary architecture the topic describes — not a replacement, a performance layer. TTL-based expiration is a simple but effective staleness strategy for many use cases. The colleague's objection reflects a misunderstanding of the complementary relationship.

Question 2

A product manager asks the backend team to use their existing Redis cluster to answer: 'Which users in New York signed up in the last 7 days?' An engineer says this is not what key-value stores are designed for. Why?

• A. Redis does not support storing user data — it is only for caching computed values
• B. Redis has no secondary indexes, so finding all keys matching a criterion requires a full scan — the O(1) model only applies to individual key lookups by exact key
• C. Redis data expires too quickly through TTL to support historical queries
• D. Key-value stores only work for session data and cannot store location or date information

Answer: (B)

The fundamental limitation of key-value stores is that retrieval requires knowing the exact key. There are no secondary indexes — you cannot query 'find all records where city = New York AND signup_date > X.' To answer that question, you would need to iterate over every key in Redis and check each value, which is O(n) and defeats the purpose. This query is exactly what relational databases with indexes are designed for. Recognizing this limitation — and routing queries accordingly — is the core skill in choosing between these storage systems.

Question 3

Redis is an in-memory store and therefore can seldom persist data to disk, making it unsuitable for any use case where data is expected to survive a server restart.

• T. True
• F. False

Answer: False

Redis supports two persistence mechanisms: RDB (Redis Database) snapshots that write a point-in-time copy of the dataset to disk at configurable intervals, and AOF (Append-Only File) that logs every write operation for replay on restart. Redis is primarily optimized as an in-memory system, and its persistence is not as durable as a transactional database with synchronous disk writes — but the claim that it cannot persist is simply wrong. Many production Redis deployments use persistence options while still benefiting from in-memory speed.

Question 4

Cache invalidation — deciding when to evict or update cached data — is a problem that key-value stores solve automatically through TTL expiration.

• T. True
• F. False

Answer: False

TTL expiration handles one specific case: time-based staleness. If data doesn't change frequently and brief staleness is acceptable, TTL works well. But if source data is updated (a user changes their profile, a price changes), the cached entry may remain stale until the TTL expires — the key-value store has no mechanism to detect or respond to changes in the underlying database. Cache invalidation strategy must be designed at the application level: either explicitly deleting or updating cache keys on writes (write-through or write-around caching), or accepting bounded staleness via TTL. This is why cache invalidation is famously described as one of computer science's hard problems.

Question 5

What is the fundamental tradeoff of the key-value data model, and why does this make key-value stores a complement to relational databases rather than a replacement?

Model answer: Key-value stores trade flexibility for speed. They provide O(1) average-case lookup by a single exact key, making them extremely fast for read-heavy workloads. But they have no secondary indexes (you can't find all records matching a field value), no joins, no schema enforcement, and no complex query support. Relational databases are slower for simple key lookups but can answer arbitrary structured queries. The right architecture uses both: a relational database as the durable, queryable source of truth, and a key-value store as a fast cache layer in front of it. Each tool does what it is designed to do — using a key-value store for complex queries, or a relational database for high-throughput key lookups, would be using the wrong tool.

The complementary architecture is the key practical takeaway. The most common mistake is viewing key-value stores as a simpler, faster alternative to relational databases — implying one replaces the other. In practice, they serve different functions and are deployed together. Redis handles session state, caching, rate limiting, and pub/sub; PostgreSQL handles transactions, reporting, and complex queries. Understanding which problems each solves well is the design skill.