The Challenge
Before Redis, the application retrieved data directly from the primary database or backend services for every request. This worked, but became inefficient when the same information was requested repeatedly, every request for frequently accessed data meant another database query or backend operation. As usage grew, this led to increased database query load, higher response times, higher CPU and resource consumption, repeated processing of the same data, and reduced performance during high-traffic periods. The core problem wasn’t that the application couldn’t function without a caching layer but it was that repeatedly retrieving the same data from the primary source was becoming inefficient at scale.
The Approach
Redis was introduced as an in-memory data store for frequently accessed information, so the application could retrieve commonly requested data from memory instead of querying the database every time. This kind of caching layer is now a standard part of how Intellinez architects SaaS platforms built for growing traffic. As workload continued to grow, a single Redis instance became a scaling consideration in its own right, with limits on memory, CPU, and request capacity. Rather than continuing to scale that single instance vertically, the approach shifted to Redis sharding: distributing the dataset and workload across multiple Redis instances so capacity could grow horizontally with demand.
Implementation
Introducing Redis as an In-Memory Cache
The data path changed from Application → Database → Response to Application → Redis → Response. When requested data is already in Redis, the application reads it directly from memory; if it isn’t, the application retrieves it from the primary source and, where appropriate, stores it in Redis for subsequent requests, reducing unnecessary database operations and freeing the database to focus on the operations that actually need it.
Scaling Beyond a Single Redis Instance
As more data and requests were handled by the same Redis server, available memory, CPU utilization, request volume, connection capacity, and overall throughput became practical limits. Simply increasing the resources of that single server was still vertical scaling, with a ceiling on how large one instance could grow — which led to the decision to introduce sharding.
Redis Sharding: Distributing the Workload
Instead of one Redis server holding the entire dataset, sharding maps different keys to different Redis instances, for example, keys A–F to Shard 1, G–M to Shard 2, and N–Z to Shard 3. This is the same principle behind Redis Cluster, where the sharding mechanism determines which instance is responsible for a given key, so the complete Redis dataset and workload no longer depend on a single server.
Distributed Memory & Workload
Sharding delivers two compounding benefits: total Redis capacity becomes the sum of every shard’s capacity rather than one server’s limit, giving the dataset room to grow; and requests are spread across multiple instances instead of concentrating on one, reducing dependency on any single instance’s CPU, memory, and request capacity. The scaling model shifts from ‘more workload → grow one server’ to ‘more workload → add more shard capacity.’
The Results
The implementation addressed two connected scaling problems in sequence, continuing the same infrastructure discipline behind Intellinez’s CI/CD automation work: introducing Redis solved the application-side performance problem, reducing repeated access to the primary data source and delivering faster access to frequently requested data. Sharding then solved the Redis scaling problem, distributing data and operations across multiple instances rather than concentrating them on one. Together, they produced a caching layer that can grow its memory capacity and request-handling ability horizontally alongside the application, instead of hitting a ceiling on a single server.
