The fastest database query is the one you never run. The fastest API call is the one that never leaves the phone.

That's the whole promise of caching, and it's why "just cache it" is the first suggestion in every performance discussion. It's also why caching causes some of the strangest bugs you'll ever chase: the price that won't update, the user who sees someone else's dashboard, the server that falls over the exact second a cache entry expires.

The way to make sense of it is to stop thinking of "the cache" as one thing. A single request can pass through four or five caches before it ever reaches your code. Let's follow one, from the outside in.

Layer 1: the browser cache

The closest cache to the user is their own browser. If it already has a fresh copy of a file, it doesn't ask the network at all. Your server controls this with response headers, mainly Cache-Control:

# app.3f9a1c.js: content-hashed file name, never changes
Cache-Control: public, max-age=31536000, immutable

# /account: personal, always check with the server first
Cache-Control: private, no-cache

# /api/payment-card: never store at all
Cache-Control: no-store

The pattern for static assets is simple and powerful: put a hash of the content in the file name (Vite does this for you), and cache it for a year. When the file changes, the name changes, so the browser fetches the new one. No invalidation needed.

The naming trap: no-cache does not mean "don't cache". It means "you may store it, but check with me before using it". The browser sends the copy's ETag or last-modified date, and if nothing changed the server answers 304 Not Modified with no body. Cheap and always correct. no-store is the one that means "don't keep this anywhere".

Layer 2: the CDN

Next, a content delivery network (CloudFront, Cloudflare and friends) keeps copies on servers close to your users. A user far from your data centre gets your images and scripts from a nearby edge instead of a round trip to your origin.

CDNs follow the same headers, with one important extra: public versus private. public means shared caches like a CDN may store it. private means only the user's own browser may. You can also give the CDN a different lifetime with s-maxage.

This is the layer where caching mistakes become security incidents. If a page with personal data is served with public caching, the CDN can hand one user's page to the next user who asks for the same URL. Anything behind a login should be private or no-store, and be careful with CDN rules that "cache everything".

Layer 3: the application cache

When the request finally reaches your app, you can still avoid the expensive work: a heavy query, a slow external API, a report that aggregates thousands of rows. This is where Redis (or Memcached, or the database or file store for smaller apps) comes in, and in Laravel it looks like this:

$stats = Cache::remember(
    "dashboard:stats:{$user->id}",
    now()->addMinutes(10),
    fn () => $this->buildDashboardStats($user),
);

remember() returns the cached value if it exists. If not, it runs the closure, stores the result for ten minutes and returns it. Three details matter more than they look:

• The key must include everything the value depends on. Forget the user ID in that key and every user sees the first user's dashboard. Include the locale, the filters, the page number, whatever changes the result.
• Cache data, not objects with baggage. Arrays and simple values serialise cleanly. Caching whole models with loaded relationships stores far more than you need and goes stale in surprising ways.
• Redis is shared. Unlike the browser cache, every server and every queue worker sees the same entries. That's what makes it useful, and what makes key design important.

Layer 4: the database's own caching

Developers often assume the database caches query results. MySQL used to have a query cache, but it was removed in MySQL 8.0 because it scaled badly under write-heavy workloads. Eloquent doesn't cache queries either.

What the database does cache is data pages. InnoDB's buffer pool keeps frequently used table and index pages in memory, which is why the second run of a query is often faster than the first. That's a good reason to give your database server enough memory, but it's not a substitute for indexes or an application cache.

The hard part, problem 1: invalidation

There's a famous line that the two hard things in computer science are cache invalidation and naming things. The reason is simple: the moment you cache something, you have two copies of the truth, and they will disagree.

You have three main tools:

• Expiry (TTL). Accept that data can be stale for up to N minutes. Simple and robust. Ideal for dashboards, counts and anything where "a few minutes old" is fine.
• Explicit forgetting. When the data changes, delete the cached copy:

  // In the Payment model
  protected static function booted(): void
  {
      static::saved(fn (Payment $payment) =>
          Cache::forget("tenant:{$payment->tenant_id}:balance"));
  }

  Precise, but you have to remember every place that affects the value. Bulk updates that skip model events will skip this too.
• Versioned keys. Put a version or a timestamp in the key ("unit:{$id}:v{$unit->updated_at->timestamp}"). When the data changes, the key changes, and the old entry simply expires unused.

My preference: use a TTL on everything, even entries you invalidate explicitly. It's the safety net for the invalidation you forgot.

The hard part, problem 2: the cache stampede

Picture a popular report cached for an hour. At the moment it expires, a hundred requests arrive. All of them miss the cache, all of them run the heavy query at the same time, and your database, which the cache was protecting, takes the full load at once. That's a cache stampede (also called a thundering herd).

Two good defences in Laravel:

// Fresh for 5 minutes; for up to 15, serve the old value
// while it's refreshed in the background after the response.
$report = Cache::flexible('reports:monthly', [300, 900], fn () => Report::monthly());

Cache::flexible() implements "stale-while-revalidate": users keep getting the slightly old value while one refresh happens behind the scenes, so nobody waits and the database isn't hit by everyone at once. The other option is an atomic lock with Cache::lock(), so only one process rebuilds the value while the others wait briefly or use what's there. Adding a little random jitter to TTLs also stops many keys from expiring at the same moment.

A quick decision list

• Static files with hashed names: cache for a year, immutable.
• HTML for logged-in users: private, no-cache, or no-store for sensitive pages.
• Expensive shared results: Cache::remember() with a sensible TTL.
• Hot keys that are slow to rebuild: Cache::flexible() or a lock.
• Data that must always be exact (balances, permissions at the moment of a payment): read from the source.

Laravel's cache documentation covers the drivers, tags and locks in detail, and MDN's Cache-Control reference is the best guide to the headers.

What's the strangest stale-cache bug you've had to track down? Bonus points if it turned out to be a layer you didn't know was caching at all.