Modern applications tend to scale to meet growing user demands and real-time expectations, the performance of backend systems becomes a crucial topic when designing architectures. Redis on SAP BTP, is often used for caching, real-time analytics, session management, leaderboard management and many other use cases. When deploying Redis on SAP Business Technology Platform (SAP BTP), a crucial yet often underestimated configuration is the shard count.
In this post we try to deep dive into why shard count matters, its advantages, and when you should consider tuning it based on your application’s needs.
What is shard count in Redis?
In the context of Redis in cluster mode, sharding refers to splitting data across multiple nodes (or shards). Each shard holds a subset of the keyspace. The shard count determines how many such divisions exist, and it uses hash slot mapping to determine where each key resides.
On SAP BTP, when provisioning Redis in cluster mode, you can configure the number of shards to match your performance and scalability goals. Please be aware the cluster mode is not available in all service plans and hyperscaler/regions, check here for more details.
Why shard count matters
- Performance through parallelism: higher shard counts allow Redis to distribute workloads across more nodes. This means more parallelism in handling reads and writes, especially under high concurrency scenarios multi-user gaming leaderboards.
- Improved resource utilization: more shards mean each shard handles less data, enabling better use of CPU and memory, it helps prevent bottlenecks on a single node and improves overall system responsiveness.
- Horizontal scalability: if you expect your data or traffic to grow, a well-configured shard count provides a scalable path forward, with Redis cluster mode you can handle this by balancing data distribution across the available shards automatically.
- Fault isolation and resilience: when using multiple shards (with replicas), node-level failures affect only a part of the keyspace, this limits the blast radius of failures and enhances high availability.
Example of use cases where shard count configuration brings value
- High-throughput applications: applications processing thousands of operations per second — such as gaming leaderboards, session management in chat applications — benefit significantly from increased shard counts.
- Large dataset caching: for systems caching complex and large result sets, distributing data across shards prevents memory exhaustion and allows efficient data access.
- Multi-tenant SaaS platforms: Redis clusters with higher shard counts can isolate data better across tenants, reducing contention and improving response time consistency.
Best practices for shard count configuration
- Start small, scale carefully: begin with a reasonable number of shards (e.g., 3 or 6) based on expected traffic, and monitor usage and performance.
- Avoid over-sharding: too many shards can introduce complexity and resource overhead.
- Ensure even key distribution: Use Redis hash tags or key design best practices to balance data across shards.
Important
Before deploying your Redis on SAP BTP configuration check here the minimum number of cache nodes per shard for the different service plans and the entitlements need.
In summary
Choosing the right shard count in Redis on SAP BTP is a architecture decision. It affects not only performance and scalability but also availability and cost-efficiency. Understanding your application’s data access patterns and workload characteristics will help you make an informed choice and set the correct configuration deployment that supports your business requirements.
Thanks for reading!
For more insights from the product team on Redis on SAP BTP, don't miss to read:
Regards,
Antonio
