Two caches with the same key and different meanings

Two services writing settings:41, one meaning customer 41 and one meaning tenant 41, against the same instance.

the collision produced:
  a customer seeing a tenant's settings, intermittently,
  for however long the TTL happened to be.

reported as: "the settings page shows the wrong data
              sometimes"
reproduced:  never, by anybody, for four months.

the fix is a prefix per service, which everybody knows
and nobody enforces:

  billing:settings:41
  identity:settings:41

Separate logical databases on one instance are the other answer and they are weaker than they look — a client with the wrong index configured writes to the wrong one, and the failure is identical. A mandatory prefix applied in the cache client’s constructor, rather than by convention at every call site, is the version that survives somebody new joining.