Caching data is one of the most important items within your application infrastructure. Without a solid data cache, scaling up your application and maintaining fast response times becomes complex and expensive . But once you have that cache in place, how often do you think about changing it?
In Terry Pratchett’s Discworld books, golems are made of clay and perform set tasks. They work constantly and consistently without rest and without fail. Sometimes, these workers are forgotten, even as the results they deliver are taken for granted. But these characters are vital to how services are delivered – in the stories, they are valuable enough to start buying themselves at a high market price. There are elements of our software and applications today that are similar.
For performance, data caching normally relies on an in-memory database like Redis. Redis is ideal for this, but once the application and the Redis instance are in production, developers then move on to other architecture considerations or projects. That application will happily carry on to provide that service as needed. However, just like the golems in the Discworld, these deployments should not be ignored.
Should you make a change?
No matter how reliable your application components are, they will need to be maintained, upgraded or replaced at some point. As elements in your application evolve, some will reach end of life status – for example, Redis 7.2 will reach end of life status for security updates in February 2026. Before that point, it’s necessary to assess the available options.
For businesses in some sectors like financial services, running out of date and unsupported software is a potential failure for regulations on security and resilience. For example, the Payment Card Industry Data Security Standard version 4.0 enforces that teams should check all their software and hardware is supported every year; in the case of end of life software, teams must also provide a full plan for migration that will be completed within twelve months. So, any component of those applications may need to be updated within a strict timeline, and your data cache component is no exception. PCI DSS applies to any organisation that is responsible for making or taking card payments, but there are other similar requirements for companies elsewhere in the financial services sector too. Even if you are not covered by regulation, you still need to have an effective long-term plan.
For companies outside this market, making a change to your caching approach might seem like a lot of work for not much return. However, support status is not the only reason why you might consider changing your application components. For example, a change in license by the software provider involved might affect your long-term planning around your infrastructure, as happened with Redis shifting to a source-available software license. For those that want to remain on an open source license, that shift meant they had to consider alternatives. Valkey, an open source fork of Redis supported by AWS, Ericsson and Percona and under the Linux Foundation, was released to offer that alternative.
At this point, it is important to flag that open source software should not be viewed as a way to cut potential costs alone. While that might be important, the real value is in how fast the community can collaborate to fix problems and add new functionality that everyone is after. This helps improve the speed of development, as well as removing potential lock-in to a single provider. If that flexibility is valued at your organisation, then a license change should be on your list of reasons for considering a shift. To go back to the banking and fintech sectors, being locked into a single supplier is something that you will have to consider for your risk and resilience requirements under the Digital Operational Resilience Act (DORA) too.
What else do you need in place?
For any software migration or upgrade, you have to understand your current deployment and your end goal. While changing out one software component might seem simple, it can rapidly flag up dependencies or other integrations that you had not considered. Auditing your systems and understanding those potential hurdles is necessary, particularly when you have sensitive or critical data to consider. Your audit will also flag any gaps in knowledge around the deployment and potential improvements from that initial deployment. Adding those dependencies to your migration plan is therefore essential to remove any potential risk.
You will also have to consider what you are migrating to – does it meet all your requirements as an enterprise in terms of security, access management or data privacy controls? While you may see one project as easy to swap out, like Redis and Valkey which are compatible with each other, there may be other requirements that you have to bear in mind. For instance, the Valkey project recently added LDAP support, which was a major requirement for any enterprise considering a migration. This crosses off a potential limiting factor that might affect whether you decide to stay with one component or make the move to one that is still open source. What’s more, the target may have considerable improvements in performance and security that you can take advantage of to provide a better, a more secure or a cheaper service by making use of those improvements.
For developers and software architects, understanding the role that any component plays in the overall application makes it easier to plan ahead. Even the most reliable and consistent component may need to change given outside circumstances. In the Discworld series, golems are so reliable that they become the standard for currency; at the same time, there are so many of them that any problem could affect the whole economy.
When it comes to data caching, Redis has been a reliable companion for many developers. However, nothing lasts forever, and there are always new software releases or alternative projects that can potentially offer better performance, improved security or easier management. Even for the most reliable components, there may be an impetus to change, whether that is inside your control or not.
The opportunity here is to get ahead of potential problems and document your decisions around technology for the long term. This makes it easier to keep your stack up to date without having to do a sudden scramble when you’re forced into it. Open source makes this process easier too, by providing alternatives that continue to innovate and keep your applications aligned with your long-term technology roadmap without unpredictable licensing changes.
Visser is the Valkey Technology Lead for Percona.