80/20 Of The Week … Caching (Part 1)
One of the most basic tools in system design…
but also one of the easiest to oversimplify lol
People usually talk about caching as just “making things faster” and yes… that is true
but caching is also about saving resources:
fewer DB queries fewer calls to downstream services lower latency less pressure on CPUs, threads, and network better stability under load
So in practice, caching is not just a speed trick…
it is also a protection mechanism for the rest of the system.
- What caching actually is
Caching means storing data that is expensive or repetitive to fetch, so the next request can get it faster.
Instead of recomputing or refetching the same thing again and again, you keep a temporary copy somewhere cheaper and faster to access.
That “somewhere” can be:
in memory inside the application a distributed cache like Redis a CDN near the user even the browser on the client side
Core idea is simple:
If the cost of fetching data again is higher than the cost of storing a temporary copy… cache it.
- What should be cached
Usually the best candidates are:
frequently requested data data that is expensive to compute data that changes less often than it is read responses shared by many users lookups, configs, metadata, product catalogs, rankings, etc.
Read-heavy and relatively stable data is where caching shines.
- What should not be cached blindly
Not everything should go into cache.
Bad candidates are often:
highly volatile data strongly consistency-sensitive data one-off queries nobody will ask again critical data where serving stale values can cause real problems
For example, account balance, payment state, or security permissions can be risky if stale data is unacceptable.
So the real question is not just:
“Can I cache this?”
It is also:
“What happens if this value is old for 5 seconds, 30 seconds, or 5 minutes?”
- What a cache usually looks like
At a simple level, a cache is often just:
key -> value
with an expiration time attached to it.
Example:
user:123:profile -> {…}
Under the hood, many caches are basically very fast key-value stores.
That is one reason Redis is so common in practice: fast, in-memory, supports TTLs, and works well when many services need shared cached data.
- Where caching starts getting more interesting
Caching sounds simple…
until real systems get involved.
Because then you start dealing with things like:
stale data invalidation cache misses and stampedes replicas and replica lag patterns like cache-aside or stale-while-revalidate
And that is where caching stops being just a speed trick and becomes a real system design topic.
- TLDR
Caching is one of the most basic optimization tools…
but it is not only about speed.
It is about reducing load, protecting resources, and keeping systems stable.
The easy part is storing data temporarily.
The hard part is deciding what to cache, how long to keep it, and how much staleness is acceptable.
Next post I’ll go deeper into how caching works in bigger distributed systems, including Redis, replicas, stale-while-revalidate, and common production patterns.
#Backend #SystemDesign #DistributedSystems #Caching #Redis #Microservices #SoftwareEngineering
