Cache-aside, read-through, write-through, and write-back

01Who owns the miss path?

An application reads product 42. The database stores its current record and a cache may hold a reusable copy. The pattern name first tells us who handles a missing copy:

• Cache-aside: application code checks the cache, reads the database on a miss and saves the copy.
• Read-through: the application asks a cache library or service; that component performs the miss load behind its interface.

Both can avoid caching unused records, but a miss is slower and many simultaneous misses can overload the source. Neither read pattern defines how writes remain current.

Two write patterns move responsibility differently:

• Write-through: the application waits for the source write and normally refreshes the cache through the same write interface. The two stores can fail separately; state exactly what success promises and how a failed cache update affects reads.
• Write-back: an intermediate buffer accepts the change first and writes the source later. The buffer now holds acknowledged changes the source may not contain; those changes are not disposable cache copies.

02Two copies do not update atomically by magic

Trace the normal read before considering failures

1. The application requests product 42's cached value.
2. On a miss, the application or read-through loader reads the source record.
3. It checks the returned version against any minimum requested by the caller and records when the source read began. It returns and caches the value only if that version and the allowed age meet the read’s rule; time spent waiting to fill the cache cannot restart its age.
4. Other callers needing the same value can share that in-progress load, called coalescing. Do not combine requests whose private data or required versions differ.

Now state the write promises

Two independent stores do not become one transaction because the pattern has “through” in its name. If the source commits but the cache change fails, explain what the caller receives, how readers avoid unsafe old data and how repair is retried without repeating the business effect.

03Worked example: stale refill and write-back loss

One illustrative write-through path

Here product descriptions may be 30 seconds old, but a successful edit promises the new database value is durable—not that every copy changed atomically.

1. The application receives the new description and request key edit-8. In one database transaction it saves product version 8, the original request/result and pending cache-refresh work.
2. In one cache operation, the application compares version 8 with the saved value and retained minimum version. It stores 8 only if neither requires a newer version, and raises the minimum to at least 8. If a newer edit has already stored 9, it keeps 9 rather than replacing it with 8. It then marks this refresh work finished.
3. If the database committed but the cache update failed, attempt to remove the old copy and leave the refresh work pending for retry. Return the saved database outcome with the cache-refresh state, not a claim that both stores committed together. A repeated edit-8 retrieves that result instead of editing again.
4. Reads needing version 8, including the editor's immediate confirmation, compare the cache’s recorded version with 8 and go to the database if it is lower or absent. Ordinary description reads may use an older copy only within the stated 30-second limit; required current permissions or stock never rely on that copy. A failed invalidation cannot extend its lifetime.

Now trace a delayed cache-aside fill

The source has product version 7. Follow a delayed fill:

1. Reader R misses, reads version 7 and pauses before writing the cache.
2. Writer W commits version 8 in the database.
3. W deletes the cached value after commit. This avoids deleting before the database change, but does not cancel R's earlier read.
4. R resumes and puts 7 into the now-empty cache. A new reader can receive old data despite database-first invalidation.
5. To reject that fill, retain a minimum acceptable version, such as 8, even when the value is absent. In one indivisible cache operation, compare an incoming fill with this marker and reject versions below it. Updates must maintain the marker too; deleting all evidence of 8 loses that protection.

That retained marker is sometimes called a tombstone or version watermark. Keep it while old delayed or replayed fills can still return. If it expires too early, the same race can reappear. Without an enforced limit on how long old fill attempts may return, no finite marker-expiry time proves they are all gone. A short TTL permits some old reads before expiry; a delayed second delete only narrows a timing window under assumptions.

This fill protection alone does not prove immediate permission revocation. Every protected read must also check current permission or participate in a coordinated rule covering cached reads, not just fills.

Now consider write-back. Five hundred accepted changes have not reached the source. If they exist only in failed volatile memory, they are lost. For a one-machine-loss promise, save each accepted change on independent durable buffer copies before replying. Keep its request ID, product version and pending status. A sender later applies it to the source using that ID/version; the source skips an already-applied ID and rejects an older version. Remove pending work only after source success. A crash before that removal causes a repeat, which those saved checks resolve. Naming the buffer a cache does not preserve missing bytes.

04Select a protocol, not only a pattern name

Choose a complete protocol, not just a pattern name:

• Replaceable reads: cache-aside or read-through can fit when reuse saves work and allowed age is explicit. Choose where loading logic is easiest to maintain and observe.
• Strict permissions or exclusive stock: use current enforced decisions unless a coordinated cache design demonstrably supplies the same guarantee.
• Write-through: show source/cache ordering, safe request retries, invalidation or repair, and what partial success means.
• Write-back: require durable accepted changes, required order, capacity limits and restart recovery. For a display title, version 9 can replace a still-buffered version 8 when only the latest title matters. Do not discard separate payments or audit events that must each be recorded.
• Load protection: limit simultaneous fills and vary expiry times to avoid synchronized reloads.

Trace cache failure, source failure, a paused reader, a crash after an effect and restart. Separate the ordinary read-cache diagram from the write-back diagram so it is clear when a buffer becomes responsible for data the source does not yet have.