When several websites share Redis, each site’s cache clears need the same boundary as its reads and writes. I check maintenance commands, counters, refresh queues and metadata keys as well as the main entries. One broad clear can undo otherwise careful namespacing.
Follow every operation
A cache has more than read and write functions. There may be a full-clear button, an automatic purge after a post save, an early page-serving path, a refresh queue and a screen which counts entries. Each one needs the same definition of which site owns a key.
I use an explicit application namespace and keep it consistent across those paths. If hostnames form part of the key, I check aliases and canonical hosts as well. A site should not accidentally create one family of keys through normal traffic and a different family through a background job.
A flush is a large operation
A database-wide flush is only appropriate when that database is dedicated to the thing being cleared and the operator intends to remove everything in it. On shared storage, it can erase another site’s warm cache, its job coordination or other application state.
The same warning applies to broad wildcard patterns. A pattern that looks specific because it contains a plugin name may still match every website using that plugin. I scope it to the site as well, and include related metadata so that a clear does not leave orphaned indexes behind.
Namespacing is not access control
A prefix prevents accidental collisions when the application respects it. It does not stop a process with broad Redis permissions from reading or deleting other keys. Where different customers or trust boundaries share infrastructure, I consider credentials, ACLs and service separation as part of the hosting design.
I also label the administration screen carefully. “Clear this site’s cache” describes a bounded action. “Clear Redis” hides the scope and makes it much harder for someone maintaining the site to judge the consequence.
Test with two sites, not one
My useful regression check creates distinct values for two fictional sites. I clear the first and verify that its pages, metadata and counters are removed, while the second site’s entries still work. I repeat the check through the normal post-save path, not just the manual button.
It is also worth checking the early cache layer. Code that runs before WordPress has fully loaded can have its own connection settings and key construction. The namespace has to survive that shortcut too.
A shared cache should behave like several labelled cupboards. Clearing one cupboard should never empty the whole room.