In our application we use lru-cache in our Express.js server to cache the response of some endpoints. Sometimes just to spare querying the database or to save time on some data transformations that we do with the data from the db (we use PostgreSQL in AWS RDS).

Our usage of cache is pretty simple. We cache something after we retrieve it from the db (and doing necessary transformations), we set ttl to, say, 1 hour. Then on subsequent request we check if we have the cached data and return it from cache in this case. If users make PUT/POST/DELETE request that leads to the change of the GET response, we clear the cache for this resource.

Our application runs in kubernetis cluster and currently it’s just one pod. However, sometimes when the load is high the app starts to struggle with CPU, and because of that we want to enable horizontal pod autoscaling. But, because currently our cache is just an object stored in memory on the server, it blocks us from enabling autoscaling. This is because if user updates a resource, and we need to reset the cache of this resource, then it will be done only in the current pod, and other users who are served by a different pod will still get cached results. To remove this limitation we want to replace our local in-memory cache with a centralised cache, that all the pods will use.

We are thinking of using Redis. However we are also considering an option of using database for this. For example we could create a “cache” table in the database with 3 columns (key, value, updatedAt) with value as JSON type and use it as our cache. If we add index by key then reads should be fast. The advantage of this solution is simplicity – we wouldn’t need to add another component in our server architecture. We already use PostgreSQL anyway so why not use it for cache too? What do you think, for this pretty basic use case, does it make sense to use table in the db as cache or Redis is better option? And if so, why would you recommend Redis over database?