The 2026 Drupal Business Survey is open. Your response will help shape the future of the Drupal business ecosystem.Problem/Motivation
If cached data is deleted on one webhead, it must be prevented that this data is used on any other webhead. The ChainedFast backend ensures this by invalidating all webhead cache data on any write to the consistent backend (see ChainedFastBackend::getMultiple).
This is very inefficient and raises the question, under which conditions is that coordination between webheads needed in the first place.
That question, and an alternative chained cache API was pioneered in the DCache module (see API).
Proposed resolution
* Provide a cache API without CacheItem::Delete, so that cache tags are the only way to invalidate cache items
* Drop the high-cost coordination-beween-webheads logic
Remaining tasks
- Add a POC
- Bikeshed
- Implement an API
- Deprecate the old API
- Profit
User interface changes
None.
API changes
API addition, then deprecation.
Data model changes
Full cache tags coverage is mandatory.
Comments
Comment #2
geek-merlinComment #3
geek-merlinComment #4
geek-merlinComment #6
berdirChainedFastBackend is meant for bins that are read often and rarely written.
On most sites, the fact that it invalidated all local storages on any cache tag invalidation was a much bigger issue and that has been changed now in #3334489: ChainedFastBackend invalidates all items when cache tags are invalidated.
When used on the proper bins and there's no misbehaving code (that does stuff like write config on any/many requests), invalidate-on-save is far more efficient than cache tags, which literally are "high-cost coordination-beween-webheads logic", as they require an extra query on every cache get.
Also somewhat related, the redis project now includes an integration with the relay php extension, which includes a native implementation that also listens on changes in redis and updates itself and therefore removes the need for the invalidate-on-save.