Innomerc Learn
English is the default.
A worked example

Five caching strategies

One exchange at a time. Read what changes, then explain it in your own words before moving on.

  1. Meet the components
  2. Follow the steps
  3. Compare an example
  4. Check your understanding
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.