Batch cache operations must preserve the request’s local view

A faster multi-key cache operation must preserve the caller's local view as carefully as an individual write or delete. Otherwise a successful mutation can leave the same request reading an old value. The optimization has changed observable behavior, even if the shared cache received the intended operation.

This retrospective concerns the week of November 4, 2026, using evidence through November 8. The November 6 Rails newsletter discusses keeping LocalCache consistent across batched writes and deletes. Its account concerns changes to the Rails codebase. It does not show that every stable release or application already includes the corrections.

Two places can hold the answer

A request-local cache avoids repeatedly retrieving the same value from a backing store during one local scope. That gives a caller two possible places from which to receive an answer. When a mutation changes the backing store, the local entry must also be handled according to the operation's contract. Otherwise the next read can continue to answer an earlier question.

The primary pull request, merged into main on November 3, describes this boundary in Strategy::LocalCache. Its account explains that single-key hooks maintained local entries, while MemCacheStore's Dalli batch paths bypassed those primitives. It describes moving handling into LocalCache's multi-entry paths so affected keys are removed locally before delegation.

That is a narrow but important distinction. The problem is not simply that remote data takes time to become visible elsewhere. The caller can hold its own older answer in the local layer. Waiting for another process to catch up would not explain why that local copy survives a mutation in the same scope.

For a hypothetical application, imagine a request that reads a cached summary, deletes its key as part of a bulk operation and then reads again to compose a response. If the local value survives, the response may contain the old summary. This illustrates the state relationship; it is not an AL+ reproduction or evidence about any customer's application.

Faster paths must carry the same obligations

A batch operation often exists to avoid repeated work. That can be a legitimate improvement when several keys need similar treatment. But implementing a new route around the ordinary primitive also creates a review question: which obligations did that primitive previously enforce on behalf of callers?

Here, the relevant obligation concerns the local layer. The caller's expectation should not depend on discovering that one public method happens to pass through a hook while another takes a faster route. Shared behavior belongs at a boundary that all relevant paths encounter, or the implementations must otherwise preserve the same observable contract.

The business implication is less mysterious than the cache terminology suggests. A user can see a stale answer immediately after an action that appeared successful. A team may then spend time examining the backing service even though the discrepancy belongs to the request's own temporary view. Clear ownership of each layer helps keep investigation focused.

That does not mean every old value has this cause. Applications can construct stale responses through many unrelated paths. The historical change supplies one specific mechanism worth understanding when the relevant store, local scope and batch operation are present. Treating it as a universal explanation would make diagnosis less precise.

Invalidate without inventing success

The newsletter also explains why the affected batch-write path drops local entries instead of directly filling them with proposed new values: set_multi does not report which keys were actually stored. The local layer should not turn an attempted write into a stronger success statement than the backing operation provides.

This is a useful design principle beyond the immediate fix. A wrapper must preserve the information its dependency actually returns. If it cannot distinguish individual outcomes, it should not create a local view that pretends those outcomes are known. Removing an earlier cached answer and establishing a new confirmed answer are different operations.

The same care applies to communicating guarantees. Keeping one local scope coherent with its mutations does not create distributed consistency across processes. It does not establish exactly-once execution, global ordering or a transaction spanning several keys. Those requirements need their own contracts and supporting mechanisms rather than being inferred from an invalidation fix.

Batching and local caching remain useful

The strongest counterargument is that both optimizations address real costs. Repeated remote reads can be wasteful, and replacing every batch with individual calls can undo useful work. A blanket recommendation to disable local caching or abandon batching would avoid explaining the actual defect while potentially discarding their intended benefits.

The better decision is to retain the optimizations where they fit and make their interaction correct. A team should identify whether its chosen version includes the relevant handling and whether its application uses the affected paths. The existence of a merged change answers neither question by itself. Those are adoption and local verification questions.

When planning such verification, the behavior worth checking is what a caller reads after mutation within the same local scope. A performance comparison alone would not answer that. This article proposes a verification target; it reports no Rails, Redis, Memcached or application experiment and no measured improvement.

Preserve the caller's contract

For software maintenance, a useful handover names the backing store, the local scope and the mutation paths that affect both. It also distinguishes upstream integration from the release installed in the application. That information lets the next maintainer assess relevance without promising a fix for every stale read.

The architectural choice is to make the faster path uphold the same local obligations as the ordinary path. Keep batching when it serves the workload. Keep local reads when their lifetime is appropriate. Require their combination to preserve the caller's view within the boundary it actually promises.