A product detail page in your catalog takes 400ms to render, and almost all of that is one database query: look up product 8842, pull its price, its inventory count, and its review summary. Every visitor runs the same query and gets the same answer. Caching keeps a second copy of that answer somewhere cheaper to read than the database that owns it, then returns it to the next reader who asks. The database can change while the copy remains, so caching requires deciding how stale a reader may be and for how long.

"We'll add a cache" is a common reflex in a system design round, but the statement leaves the important decisions open. You still need to choose a cache layer, explain how reads populate it, define what writes do, and set a justified TTL (time to live). You also need to state the staleness window and the failure modes instead of claiming that the cache stays in sync.