Write paths and cache-aside races

In a write-through design, a write passes through a caching layer toward backing storage, but exact acknowledgment and atomicity still depend on the implementation. Do not assume that two systems update transactionally merely because the application calls them in sequence. If the origin commits and the cache update fails, choose whether to invalidate, retry, or tolerate a bounded stale entry. A successful response should match the documented durability and visibility contract, including crash behavior.

Write-back or write-behind can acknowledge before the authoritative destination has received the update. The intervening dirty state therefore needs a durable queue or log if acknowledged writes must survive failure. Ordering, deduplication, retries, and replay determine whether a restarted worker can safely drain that state. Evicting a dirty entry is not equivalent to evicting a disposable read replica. Capacity planning must include undrained changes and their failure semantics, not just ordinary cache values.

In cache-aside, a miss commonly reads the origin and later fills the cache; a writer commits to the origin and invalidates the cached key. Consider a reader that fetches old version 10 and pauses. A writer commits version 11 and deletes the key. The reader then stores version 10, resurrecting stale data after the invalidation. Delete-after-commit did not fail to execute; its ordering simply did not fence the already in-flight old fill.

A second delayed delete can reduce exposure under timing assumptions but is not a proof under arbitrary process pauses and network delays. Stronger designs can use source versions, generation-checked fills, or a source-of-truth protocol that makes stale publication fail. Any version floor or tombstone must survive long enough and in the right failure domain to reject delayed work. Strict freshness requires a stronger argument than a TTL eventually removing the stale value.

Exercise every boundary independently: origin commit before cache failure, cache acknowledgment before persistence failure, duplicate write replay, delayed fill, and invalidation loss. Observe the returned write result and what later reads can actually see after restart. Use idempotent source operations or operation identities where retries can repeat work, and make ambiguous outcomes explicit. Changing a pattern for performance must not silently weaken durable-write or read-after-write expectations that callers already rely on.

The queue lab illustrates a dirty-work capacity gap only. Reset and set both λ=4, μ=2, predict six queued units at t=1, then use two Steps. For a separate run Reset and re-set λ=2, μ=4, predicting two at t=1. These are fluid jobs starting at four, not persisted bytes or a write-back log. The model contains no cache-aside race, transaction, acknowledgment, or crash recovery. Use it to state why an indefinitely slower persistence path needs backpressure or a bounded failure policy.