technical · warmup
What is the difference between a database and a cache?
What is the difference between a database and a cache?
This is a technical literacy check, not a system design question. The interviewer wants to know if you can reason about infrastructure tradeoffs and connect them to product decisions, not whether you know Redis internals.
Structure a strong answer
strong
"A database is your source of truth. It persists data to disk, survives restarts, and supports complex queries. A cache is a faster copy of a subset of that data, held in memory, that expires or gets evicted. Reading from Redis takes about 1ms; reading from Postgres takes around 50ms. That 50x gap is why high-traffic products cache aggressively.
The real tradeoff is not fast versus slow. It's freshness versus cost and latency. Between the moment you write to the database and the moment the cache expires, the two are out of sync. For a Spotify recommendation feed or a Twitter timeline, a few seconds of staleness is fine. For a bank balance or a concert ticket count, you never cache. Stale data causes real harm there, and no latency improvement is worth it."
weak
"A database stores data persistently on disk and supports complex queries. A cache stores data in memory for faster access." Accurate, but this is a dictionary answer. It tells the interviewer nothing about your judgment. Candidates who stop here can't follow up on: "when would you cache user profile data versus always hit the database?" They have no mental model for consistency risk, cost, or the product contexts where staleness hurts users.
The PM judgment
The interviewer is checking three things: that you understand the mechanical difference, that you can frame the tradeoff in product terms, and that you know when not to cache.
The mechanical difference. A cache stores data in RAM, which is volatile. Restart the process, you lose the data. A database stores on disk and survives restarts. Cache hit means the data was found in cache and served immediately. Cache miss means it was not there, so the system fetched from the database (and usually wrote the result back to cache).
The tradeoff that matters. Caches can reduce database load by 80 to 90 percent under read-heavy workloads. That is the business case for caching: it makes products viable at scale. But cache invalidation is the hard problem. Keeping the cache and database in sync after a write is where most bugs live in production. Three strategies PMs should know by name: cache-aside (check cache first, fall back to database on miss, most common), write-through (every write updates both simultaneously, safer but slower writes), write-behind (write to cache first, sync to database asynchronously, faster but riskier).
What to never cache. Real-time financial balances. Live inventory like airline seats or concert tickets. Personal health data where staleness has legal or safety implications. On these, the freshness SLA is zero.
The 2026 layer. Caching is now a first-class product decision in AI systems. If your product serves LLM-generated summaries or RAG responses, do you cache the output? A cached AI answer costs nothing to serve and is fast. But it carries two staleness risks: the underlying facts may have changed, and the model’s reasoning at generation time may have been wrong. Semantic caches (used by Perplexity, Glean, and others) match similar queries rather than identical ones, which introduces a new failure mode: a semantically close but contextually different query gets a wrong cached answer. The PM question is: what is the freshness SLA for this response, and what is the cost of stale content to the user? Annoying, harmful, or legally liable are three very different answers.
What Databricks and Anthropic interviewers add
At data infrastructure companies like Databricks, expect a follow-up on the hot key problem: if one cache key gets millions of simultaneous requests (a viral event, a global leaderboard), a single cache node becomes the bottleneck even with caching in place. At AI labs like Anthropic, expect the conversation to move directly to LLM response caching and your reasoning about staleness thresholds per content type.