In-memory data cache services like Redis on SAP BTP offer exceptional performance for real-time applications. However, memory is a finite resource. When Redis instances are deployed on SAP Business Technology Platform (SAP BTP), efficient memory management becomes even more critical to ensure high availability, stability, and cost-effectiveness of services. This is where eviction policies come into play.
In this blog post, we’ll try to explain what eviction policies are, when and where to use them in your SAP BTP deployments, their advantages and limitations, and how to choose the right policy for your use.
What is an eviction policy in Redis?
Redis on SAP BTP stores cache data in memory, making access times extremely fast. But if memory becomes full, Redis must decide what to do with new incoming data. That’s where eviction policies help—below are strategies (options) that Redis uses to free up space by removing certain keys.
The service supports multiple eviction policies, such as:
- noeviction: reject new writes once memory is full.
- allkeys-lru: evict least recently used keys across all keys.
- volatile-lru: evict least recently used keys with an expiry set.
- allkeys-random: evict random keys.
- volatile-random: evict random keys with expiry.
- volatile-ttl: evict keys with the shortest time-to-live.
- allkeys-lfu: evicts the least frequently used keys
- volatile-lfu: evicts the least frequently used keys with an expiry set.
By default Redis on SAP BTP service is set to eviction_policy = noeviction
Check here the different policies available and how to change the parameter.
Why eviction policies matter on SAP BTP
Redis on SAP BTP is often used for:
- Caching APIs or database query results.
- Session storage in cloud-native apps.
- Leaderboards or real-time analytics.
- and many other use cases.
In each of these cases, uncontrolled memory usage can degrade service quality or even crash your app. SAP BTP allows you to provision Redis with specific memory configuration, and eviction policies help you stay within those constraints without disruption.
Advantages of using eviction policies
- Prevents out-of-memory (OOM) Errors: Redis stays operational under memory pressure.
- Fine-grained control: customize eviction behavior to match data importance and application usage patterns.
- Improved cost efficiency: stay within your instance memory configuration on SAP BTP avoiding overprovisioning.
Best practices for using eviction policies
- Always use TTLs for cacheable or transient data.
- Use memory setup wisely: match the configuration to your use case, then pick an appropriate eviction policy.
- Test under load: simulate memory exhaustion to observe eviction behavior before production deployment.
- Separate critical from non-critical data: using key namespaces or even multiple Redis instances.
Final thoughts
Eviction policies are not one-size-fits-all. Choosing the right one requires understanding of your application’s access patterns and data lifecycle. For running applications in the cloud the cost and stability are key, a smart use of eviction policies ensures Redis on SAP BTP remains both performant but also predictable.
Thanks for reading!
For more insights from the product team on Redis on SAP BTP, don't miss to read:
Regards,
Antonio
