Innomerc Learn
English is the default.
Web & Backend Technology

How Caching Works

Compare a cache hit with a miss, and see why freshness and cache keys are security decisions too.

Foundational6 min explorationReviewed
My learningNot started

Choose your depth. Learn at your own pace.

Simple explanation

Understand it

A cache keeps a reusable copy so the next request can avoid repeating expensive work. A hit means a usable copy is found. A miss means the application must obtain the data elsewhere, often from its source of truth.

The copy can become old. For a fictional product catalog, a slightly delayed description may be acceptable; an outdated account permission may not be. The system must decide what can be reused, by whom and for how long.

Technical explanation

Under the hood

In cache-aside, the application checks the cache, loads from the database on a miss and populates the cache. Write-through updates the cache and backing store in a coordinated write path; write-back defers backing-store writes and requires careful durability design.

HTTP caching distinguishes private browser caches from shared caches. Cache-Control directives and validators govern reuse and revalidation. “No-cache” allows storage but requires validation before reuse; “no-store” directs caches not to store the response.

Practitioner explanation

Practitioner perspective

Cache keys must represent every relevant dimension, including tenant or user when responses differ. A high hit ratio is not success if private data crosses an authorization boundary. Vary and normalization behavior must match the application’s interpretation.

Plan invalidation, stampede protection, TTL jitter and behavior when the cache is unavailable. Measure stale responses and origin load, not just latency. Authorization changes and secret revocation often demand stronger freshness guarantees than ordinary content.

See the decision happen

Watch it work

A fictional, simplified model. Select a component to inspect it, or follow the steps in order.

Interactive Lab

Five caching strategies

Watch who reads, who writes, and when the application gets its answer.

Steps1. GET key 2. SELECT 3. Value 4. SET + TTL
Click a box or choose its name to learn what it means.
ApplicationReadyCacheReadyDatabaseReadyApplicationReadyCacheReadyDatabaseReady
Ready to traceCache aside
Before you start · 4 stepsCache aside

The application owns cache population. Writes need a deliberate invalidation policy.

How to use this example

Select Next step to read at your own pace, or Animate step to watch one exchange. Nothing advances until you choose.

Inspect components & read every step
  • Application

    Software that carries out a task for its user.

    Example: A timetable app looks up the next bus departure.

  • Cache

    A stored copy used to answer some requests faster. Copies can become outdated.

    Example: An app reuses a recently fetched timetable instead of fetching it again immediately.

  • Database

    An organized store of records that software can read and update.

    Example: A shop stores product quantities and order records.

Cache aside

The application owns cache population. Writes need a deliberate invalidation policy.

  1. Application Cache: GET key. The application checks for a cached value.
  2. Application Database: SELECT. On a miss, the application queries the database.
  3. Database Application: Value. The authoritative value returns to the application.
  4. Application Cache: SET + TTL. The application populates the cache for later reads.

Read through

The cache layer loads missing data on the application’s behalf.

  1. Application Cache: GET key. The application calls the cache layer.
  2. Cache Database: Load. The cache loader fetches the missing value.
  3. Database Cache: Value. The cache stores the result.
  4. Cache Application: Value. The application receives the value through the cache.

Write through

This model acknowledges only after the backing write succeeds.

  1. Application Cache: WRITE. The application submits a write through the cache.
  2. Cache Database: Persist. The cache layer writes the backing database.
  3. Database Cache: Commit OK. The backing write is confirmed.
  4. Cache Application: ACK. Only now is success returned.

Write around

Bypass cache on write; invalidate old entries to avoid stale reads.

  1. Application Database: WRITE. Write directly to the backing store.
  2. Application Cache: Invalidate. Remove any stale cached value for this key.
  3. Application Cache: Later GET. A later read misses the cache.
  4. Application Database: Read latest. The application retrieves the current value.
  5. Application Cache: Populate. Populate under the selected read policy.

Write back

A cache acknowledgement is not yet database durability.

  1. Application Cache: WRITE. The cache accepts the new value.
  2. Cache Application: Early ACK. The application gets an acknowledgement before the database write.
  3. Cache Database: Async flush. A later flush persists the dirty value; failure before durable storage is a risk.
  4. Database Cache: Confirmed. The cache can mark the value clean.

Fictional teaching trace. One moving dot represents an exchange, not a measured network capture.

Open the detailed lesson walkthrough

Explore the system

Request

The application needs the product description.

1 / 5

Takeaway A miss performs origin work and can prepare a later hit.

Read every step without animation

Cache miss

  1. Request. The application needs the product description.
  2. Cache lookup. No fresh entry matches this key.
  3. Database. The application reads the source of truth.
  4. Populate cache. A reusable copy is saved with its expiry policy.
  5. Response. The description is returned.

A miss performs origin work and can prepare a later hit.

Cache hit

  1. Request. The same permitted product request arrives.
  2. Fresh entry. The cache has a usable entry for the exact key.
  3. Response. The entry returns without a database query.

A hit saves work only when reuse is correct.

Tenant-aware key

  1. Tenant A. The request carries verified tenant context.
  2. Scoped key. The cache key includes the relevant tenant boundary.
  3. Isolated response. Tenant B’s cached data cannot match this key.

A fast answer must still be the right user’s answer.

Explore deeper: additional experiment
Change an input. Inspect the consequence.

Will this cache cross a tenant boundary?

HIT cached response

The tenant matches and the entry is fresh. Authorization and invalidation requirements still apply.

A local teaching model with fictional inputs. It does not test a live system.

Attack view

A cache key that ignores tenant identity can reuse one customer’s response for another. This is a design error even if the cache is functioning exactly as configured.

Defender view

  • Avoid shared caching of personalized responses unless isolation is explicitly correct.
  • Choose keys and invalidation rules based on data semantics.
  • Treat cache failures and cold starts as expected operational conditions.

Common mistakes

  • A cache is not automatically the source of truth.
  • No-cache and no-store do not mean the same thing.

Check your understanding

Which instruction prohibits storing an HTTP response?
Active recall: explain this idea in 30 seconds

A cache keeps a reusable copy so the next request can avoid repeating expensive work. A hit means a usable copy is found. A miss means the application must obtain the data elsewhere, often from its source of truth.

Now give an example and name one limitation. Revisit the explanation if you get stuck.

Primary sources

Original explanations informed by these specifications and official resources. Source versions and lesson review are separate from product updates.

Content reviewed 2026-09-10. Read the editorial policy.

What comes next?

Technology fundamentals

Back to topic