Overview
An operator had grown 41 Redis instances over several years, on Kubernetes and on virtual machines in two data centres, used for sessions, rate limiting and provisioning caches. After the Redis licence change the platform team wanted a decision on Valkey backed by evidence.
Challenge
Instances ran Redis 6.2, 7.0 and 7.2 with clients in Java, Python and Go on different library versions. Some used Lua scripts for rate limiting, two relied on a Redis module, and monitoring tools parsed the version string. Nobody could say which instances would move without surprises.
Environment
41 Redis instances: Sentinel pairs on virtual machines, Redis Cluster on Kubernetes, one managed cloud instance. Lua scripts for rate limiting and provisioning, Prometheus exporters and custom health checks.
Approach
AceMQ engineers sampled INFO commandstats on every instance to see which commands were really used, extracted and reviewed the Lua scripts, mapped client libraries and versions to each service, and checked tools that read the server version. Instances were scored by risk and sequenced, with replication-based cutover as the default method.
Solution
- Sampled command usage per instance and compared it with the command set Valkey supports
- Reviewed every Lua script and the keys and commands each one touches
- Mapped client libraries and versions per service, and tested each against a Valkey replica
- Found monitoring and health checks that depended on the version string Redis reports
- Separated the two module-dependent instances for their own decision rather than a bulk move
- Produced a sequenced migration plan with replication cutover and a rehearsed rollback per wave
Outcome
Of 41 instances, 34 were ready for replication-based cutover, five needed a client library upgrade first, and the two module instances stayed on Redis for the time being. The team started the first wave knowing which risks were left rather than hoping none existed.
Technologies
Valkey
Redis
Kubernetes
Terraform
Prometheus
NGINX
