Caching and Redis
Caching and Redis work covers sizing the instance, deciding which keys may be evicted and setting how the application behaves when Redis restarts. It applies where sessions, queues and cached values share one instance.
What ends up inside Redis
Sessions, cached values and job queues often share one instance, and each tolerates data loss differently. Separating them is worth the effort.
Memory, eviction and hot keys
Redis fills up. What happens then is either decided in advance or discovered at the worst moment.
When Redis restarts
Servers reboot, memory fills and providers run maintenance. An application should keep working while the cache is empty.
Frequently asked questions
Do we need Redis at all?
Not always. A small site with a well-indexed database often gains little from it and adds a service to maintain. Redis is suggested when measurement shows repeated expensive work.
Can Redis run on the same server as our application?
Yes, on a single modest server, with a memory limit set so it cannot starve the application. Once traffic grows or several servers share it, a separate instance or a managed service is steadier.
Is a managed Redis service worth paying for?
It depends on who handles backups, upgrades and failover. Where nobody on your side wants that job, a managed service fits. Either option can be set up, and the self-hosted route is called out where it suits your size.
Tell us what you need.
Share your requirements and one of our engineers will come back to you within one business day.
- No obligation
- A reply within one business day
- Your details stay private
Start with your requirements
Seven short steps that tell us what you need. An engineer reads them before getting in touch.
Share your requirements