Caching Strategies
Start here
Caching Strategies is a chapter of the System Design Masterclass course.
- 1.Local Cache24 min · free to readFree
- 2.Cache Eviction Policies24 min · free to readFree
- 3.Cache-Aside Pattern25 min · the opening is free to read
770 lessons · 18 free to read
₹1,111 in India · $25 elsewhere, once
Get System DesignYou own this course
A cache is a smaller, faster copy of data kept close to whoever needs it, so you don't pay the full cost of fetching it every single time. When Amazon found that 100 milliseconds of extra latency cost them 1 percent of sales, the fix was rarely a faster database. It was a cache sitting in front of the slow thing, answering most requests in microseconds instead of milliseconds. Almost every fast system you have ever used is fast because something was cached.
Caching looks simple from the outside: store the answer, reuse it. The hard part is everything around that. Where do you put the cache. How long do you keep each entry before it goes stale. What happens when a thousand requests all miss at the same moment. How do you keep the cache and the source of truth from drifting apart. This category walks through every layer where caching happens, the read and write patterns that make it correct, and the real tools teams reach for in production.
36 lessons in this topic · start with any of them
This page is the free part.
The course goes deeper on Caching Strategies
₹1,111 in India$25 everywhere elseonce, for the whole course
The System Design course covers Caching Strategies across a run of lessons, not one page. These 4 alone are about 96 minutes of step-by-step reading, every one with a quiz.
- Local Cache
The fastest cache you can have, and the only one that can disagree with itself.
- Application Cache
The cache your own code manages, the race hiding in its default pattern, and how often that race actually fires.
- Browser Caching
The only cache with no purge, the only one that can answer with no network, and why revalidation gives up the thing that makes it valuable.
- Client-Side Caching
A cache your code keeps on the user's device, why the usual objection to it is measurably wrong, and what actually limits it.
all part of
System Design Masterclass
770 lessons · about 287 hours · 18 free to read
₹1,111in India, by UPI
$25everywhere else, by PayPal
It is really nice and good Please join the course
You own this course
Continue with Local Cachepay once,
yours for life
What Caching Is and Where It Lives
A cache trades freshness and memory for speed. Instead of recomputing a value or hitting the database again, you keep the result somewhere fast and hand it back on the next request. The win comes from locality: the same data tends to get asked for repeatedly, so storing it once pays off many times.
The surprising thing for newcomers is how many places a cache can sit. There is caching inside a single process with Memoization, where a function remembers what it already computed. There is the Local Cache and Application Cache living in your service's own memory. Move outward and you hit Server-Side Caching, Database Query Caching, and Result Set Caching, which stop expensive queries from running twice. Move toward the user and you find Client-Side Caching, Browser Caching, and Edge Caching at the CDN, which serve responses before a request ever reaches your servers.
Each layer catches a different class of repeated work. A mature system uses several at once: the browser caches assets, the CDN caches pages, the app caches query results, and the database caches its own hot rows. The art is deciding which layer should own each piece of data.
Read and Write Patterns
Once you decide to cache, you have to choose how the cache and the database stay in sync. On the read side, the Cache-Aside Pattern is the workhorse: your code checks the cache first, and on a miss it loads from the database and fills the cache itself. A Read-Through Cache hides that logic behind the cache layer, so the application just asks the cache and the cache handles the miss.
Writes are where teams get burned. A Write-Through Cache updates the cache and the database together on every write, keeping them consistent at the cost of slower writes. A Write-Back Cache updates the cache immediately and flushes to the database later, which is fast but risks losing data if the cache dies before the flush. A Refresh-Ahead Cache predicts which entries are about to expire and reloads them in the background so users never wait on a refresh.
The theme is that there is no free lunch. Faster writes mean weaker consistency. Stronger consistency means the cache buys you less. Picking a pattern is really picking how much staleness your product can tolerate, and for which data.
Keeping the Cache Honest: Expiry, Eviction, and Invalidation
A cache that never forgets is just a slower, staler copy of your database. Three mechanisms keep it honest. Time-to-Live (TTL) stamps each entry with an expiry so stale data eventually clears itself out. Cache Eviction Policies (LRU, LFU, FIFO) decide what to drop when memory fills up, because a cache is deliberately smaller than the data it fronts. Cache Invalidation actively removes or updates entries the moment the underlying data changes, which Phil Karlton famously called one of the two hard problems in computer science.
The failure mode everyone eventually meets is the cache stampede, also called the thundering herd. A popular entry expires, a thousand requests miss at the same instant, and all of them slam the database together. Cache Stampede Prevention handles this with locks, staggered TTLs, or serving slightly stale data while one request rebuilds the entry.
Loading strategy matters just as much as expiry. Lazy Loading fills the cache only when something is first requested, so cold entries pay a one-time penalty. Eager Loading and Cache Warming populate the cache up front so the first user never hits a cold miss. Prefetching and Predictive Prefetching go further, loading data the system expects you to ask for next, the way Netflix preloads the next episode before the current one ends.
Distributed Caching and the Tools That Power It
A cache living inside one process is fast but isolated. The moment you run more than one server, you want a Remote Cache or Distributed Cache that all instances share, so a value cached by one machine is available to the rest. This is where Fragment Caching also fits, storing reusable pieces of a rendered page so each server doesn't rebuild the same HTML.
The tooling splits along clear lines. Redis Cache is the default distributed in-memory store, with rich data types, persistence, and pub/sub. Memcached is leaner and built purely for simple key-value caching at scale. Varnish Cache sits in front of web servers as an HTTP accelerator. On the JVM side, Caffeine Cache and Guava Cache are high-performance local caches, while Ehcache, Hazelcast, Apache Ignite, and Coherence offer distributed and in-memory data grid options for clustered Java systems.
No single tool is best. You pick based on what you are caching and where. A read-heavy web tier might run Varnish at the edge and Redis behind the app. A Java microservice might use Caffeine for hot local data and Hazelcast for shared state. Knowing the strengths of each, rather than reaching for Redis by reflex, is what separates a working cache from a well-designed one.
All 36 lessons in Caching Strategies
- 01Local Cache
- 02Application Cache
- 03Browser Caching
- 04Client-Side Caching
- 05Time-to-Live (TTL)
- 06Memoization
- 07Application-Level Caching
- 08Server-Side Caching
- 09Database Query Caching
- 10Result Set Caching
- 11Cache Eviction Policies (LRU, LFU, FIFO)
- 12Cache Invalidation
- 13Lazy Loading
- 14Eager Loading
- 15Prefetching
- 16Predictive Prefetching
- 17Cache Warming
- 18Cache-Aside Pattern
- 19Read-Through Cache
- 20Write-Through Cache
- 21Write-Back Cache
- 22Refresh-Ahead Cache
- 23Cache Stampede Prevention
- 24Remote Cache
- 25Edge Caching
- 26Fragment Caching
- 27Distributed Cache
- 28Redis Cache
- 29Memcached
- 30Varnish Cache
- 31Hazelcast
- 32Apache Ignite
- 33Coherence
- 34Ehcache
- 35Caffeine Cache
- 36Guava Cache
Frequently asked questions
Learn Caching Strategies the interactive way
All 36 lessons with step by step diagrams, runnable code, and quizzes, plus the rest of the 770 lessons in the course. One payment, lifetime access, no subscription.
course 1
System Design Masterclass
From absolute beginner to principal engineer, drawn step by step.
- 770 interactive lessons
- Step-by-step system design diagrams
- Live code editors
- Quizzes with instant feedback
- Progress tracking and streaks
- Lifetime access and all future lessons
What buyers of this course say
It is easy and good
It is really nice and good Please join the course
The concepts were explained in a clear and structured way, with practical examples that made even complex system design topics easier to understand. I especially liked the focus on real-world architecture, scalability, trade-offs. The content was well designed, engaging, and highly useful for anyone looking to strengthen their system design skills. Highly recommended for software engineers preparing for system design interviews or wanting to build a stronger foundation in designing scalable systems.
Outstanding all-in-one source of knowledge, especially excellent practice
Ive started this course by accident - LLM advised me this site. When I passed few free lessons, I had no doubt - this course should be bought. And I did it with special pleasent price and it was best decision of the month. Content is great, interesting to read and with a lot of practial cases (what makes it different from other souces and books) I hope to teach all the lessons, that will be my supergoal. Glad that I found this resource and speacial Thank You to Roni Das - Great Job!