One Valkey, Multiple Tenants: Per-Database Isolation on Kubernetes

The default answer when a microservice needs a cache is to give it its own instance. It works, but it means a cluster running ten services has ten Valkey deployments sitting at 2% utilisation each. Valkey 9.1.0 changes the consolidation calculus with per-database ACL selectors: a single db=N directive locks an ACL user to one logical database at the protocol level. A misconfigured service physically cannot read another tenant’s keys. This talk walks through a production-style demo: ten Go microservices sharing one Valkey instance on Kubernetes, each locked to its own logical database via the official Helm chart. We cover the ACL config, how Kubernetes Secrets wire per-tenant credentials, load test results across three k6 scenarios (steady 10K RPS, ramp, spike), and the honest caveat: db=N gives you access isolation, not resource isolation. You leave with a working pattern, a load-tested architecture, and a clear picture of where it holds and where it does not.This talk walks through a production-style demo: ten Go microservices sharing one Valkey instance on Kubernetes, each locked to its own logical database via the official Helm chart. We cover the ACL config, how Kubernetes Secrets wire per-tenant credentials, load test results across three k6 scenarios (steady 10K RPS, ramp, spike), and the honest caveat: db=N gives you access isolation, not resource isolation. You leave with a working pattern, a load-tested architecture, and a clear picture of where it holds and where it does not.