If you've ever wondered why every backend system you read about has a cache sitting somewhere in the architecture diagram, this is the "why" behind it, explained the way I actually understood it, not the textbook way.
The problem: repeated reads that don't need to happen
Imagine a database that many users hit to read the exact same piece of data. Not different data, the same data, over and over. Every single one of those reads goes all the way to the database, even though nothing about the data has changed between requests.
That's wasted work. The database is doing the same job a thousand times when it could have done it once and reused the result.
This is the core problem caching solves: reduce the number of calls to the database, so the load on it goes down.
The idea: a cache is your bookshelf's front shelf
Here's a way to think about it that isn't technical at all.
You own a lot of books, that's your database, full of everything you might ever need. But at any given time, you're only reading one or two of them. So instead of digging through your entire collection every time you want to read, you keep those one or two books on a small shelf near you, within easy reach.
That small shelf is the cache. The full bookshelf is the database.
When you want a book, you check the small shelf first. If it's there, you grab it instantly, no digging required. If it's not there, you go to the full shelf, get it, and maybe put it on the small shelf too, in case you want it again soon.
That's exactly what a cache does for an application: it sits in front of the database and answers requests directly when it can, so the database only gets hit when it actually needs to be.
## Not everything belongs in the cache
This is the part that's easy to get wrong if you don't think about it carefully: caching isn't "store everything so it's faster." Some data is genuinely a bad fit for caching.
Two questions decide whether something belongs in a cache:
Does this data stay mostly the same over time?
An address, a profile, a famous post that almost nobody edits, a piece of content that's already been uploaded and is just being viewed by more and more people, these don't change often. If you cache them, you're not risking showing outdated information very often.
Do a lot of people ask for this same data repeatedly?
If a specific row in a database keeps getting looked up over and over by different users, that's a strong signal it belongs in a cache, every time you serve it from cache instead of the database, you save a real, repeated cost.
If both of these are true, data that's stable and gets read a lot, it's a strong candidate for caching.
Now compare that to something like a one-time password (OTP). An OTP is generated, read exactly once by the user trying to log in, and then it's invalid forever. There's no repetition to save on, you're never going to serve that same OTP to a second request. Caching only pays off when you're avoiding repeated work, and here there isn't any. So caching an OTP buys you nothing.
This is the actual test, not a rule to memorize: is this data read often relative to how often it changes? If yes, cache it. If it's read once and never again, don't bother.
The catch: caches can lie to you
Here's the part that doesn't show up in the simple explanation, but matters a lot once you actually build something.
When you cache data, you're keeping a copy of it, separate from the real source (the database). That copy is only correct as of the moment it was cached. If the real data in the database changes after that, your cache doesn't automatically know about it, it just keeps serving the old copy.
This is called staleness: the cache falling behind the database, showing users information that's technically already outdated.
To manage this, caches use something called a TTL, Time To Live. It's basically a timer attached to each piece of cached data, saying "treat this as valid for this long, and after that, go check the real database again." It doesn't eliminate staleness, but it puts a bound on how outdated the cache is allowed to get.
There's also an order-of-operations detail that matters more than it seems: when data changes, you should write it to the database first, and then update the cache, never the other way around. If you update the cache first and something fails before the database write actually happens, you end up with a cache confidently serving data that was never actually saved anywhere real. That's worse than staleness, that's just wrong data being treated as truth.
Why this actually matters
Caching sounds like a small performance trick, but the reasoning behind it, reduce repeated work, know what's worth storing versus what isn't, and understand the tradeoff you're accepting (staleness, in exchange for speed and lower load), is a pattern that shows up constantly once you start looking for it. It's not really about memorizing "what caching is." It's about being able to reason through when it helps and what it costs you when it does.
Connect with me:
GitHub: github.com/MrBlackGhostt
LinkedIn: linkedin.com/in/mrhemantkumarr
X: @hksoldev
YouTube: youtube.com/@MrDevGhost
Instagram: instagram.com/mr.devghost
Top comments (0)