Cache Tag Invalidation Limits in Multi-Server Clusters

Direct Answer

No. TYPO3's cache tag invalidation does not guarantee atomic updates across all nodes in a multi-server cluster. When nodes share a Redis or Memcached backend, removing a tag's keys is visible to every node because they read from the same store. However, the invalidation routine does not coordinate with concurrent writes on other nodes, so a node can briefly serve stale data while another node is writing a replacement.

Confirmed Facts vs. Likely Explanation

Confirmed: TYPO3 stores each cache tag as a separate key in the shared backend. A tag-based flush deletes those keys, and every node sees the deletion immediately because they query the same Redis or Memcached instance.

Likely explanation: The invalidation path does not use a distributed lock or transaction. Under concurrent traffic, a write on Node B can interleave with a tag deletion initiated on Node A. The result is a short window where a node may return a stale entry until the backend state settles.

Limits of the Tag-Based Flush Process

The flush triggered by cache-tag invalidation has practical boundaries in a cluster:

• Linear scaling: The process iterates over the affected tags and issues backend deletions one by one. Flush time grows with tag count, so large invalidation sets can add latency.
• Coarse Memcached behavior: Depending on the backend implementation, a tag flush in Memcached may rely on flush_all rather than targeted deletes, clearing unrelated entries if the instance is shared with other applications.
• Local cache bypass: Tag invalidation only touches the shared backend. Local opcode caches (e.g., APCu) or other node-local stores are unaffected and can retain stale data independently.
• No cross-node barrier: There is no mechanism that pauses reads or writes on all nodes while the flush completes.

Verification Steps for This Case

1. Confirm every node uses the same Redis or Memcached backend and that no node has a divergent local cache fallback.
2. Check whether APCu or another local user/opcode cache is active on the cluster nodes; disable it for cache entries that must be cluster-consistent.
3. Review the backend TTL and persistence settings. Long TTLs can preserve stale entries if a tag delete is missed or delayed.
4. Measure flush latency by timing $cache->flushByTag($tag) for varying tag counts and confirm the time increases with tag set size.

Version note: Cache backend internals differ across TYPO3 releases. Verify the exact tag-key formation and deletion calls in your installed Core/Cache/Backend classes before relying on these limits.

One Missing Diagnostic

To refine the recommendation, please confirm whether APCu (or a similar local cache) is enabled on the nodes and what TTL/persistence configuration the Redis or Memcached backend uses. That detail determines whether you need a versioned cache identifier or a post-flush warming step.