Engineering Note
We were trying to make one Rails page faster. The real problem was that we were caching at the wrong layer.
The application was serving a SaaS dashboard with repeated requests for the same data.
Our first instinct was Redis.
It helped, but response times were still higher than expected.
Then we looked at the request path:
Browser → CDN → Rails → Redis → PostgreSQL
We realised different layers were solving different problems.
So we split the caching strategy:
* CDN for static assets and cacheable public responses
* Redis for expensive application data
* HTTP cache headers to let browsers and proxies avoid unnecessary requests
One endpoint was averaging around 900ms.
After moving the right work to the right layer, it dropped to around 180ms.
More importantly, database traffic dropped by roughly 40%.
The lesson?
Caching isn't just:
"Should we use Redis?"
The better question is:
"Which layer should cache this data?"
Adding another cache won't automatically make a system faster.
The architecture has to decide where the work should stop.
Our first instinct was Redis.
It helped, but response times were still higher than expected.
Then we looked at the request path:
Browser → CDN → Rails → Redis → PostgreSQL
We realised different layers were solving different problems.
So we split the caching strategy:
* CDN for static assets and cacheable public responses
* Redis for expensive application data
* HTTP cache headers to let browsers and proxies avoid unnecessary requests
One endpoint was averaging around 900ms.
After moving the right work to the right layer, it dropped to around 180ms.
More importantly, database traffic dropped by roughly 40%.
The lesson?
Caching isn't just:
"Should we use Redis?"
The better question is:
"Which layer should cache this data?"
Adding another cache won't automatically make a system faster.
The architecture has to decide where the work should stop.