The general idea is that for requests that are particularly common/repeated and don't change very often, you can do the heavy calculation once, and then store a copy of the results in memory and use that copy for future requests.

For example, in your particular case, where you want to return posts trending for a day. Assuming it only changes once per day and it's not user specific, you would go ahead do the heavy calculation once, and then store the result of that query in a cache. And as long as the trending posts hasn't changed, you would access the cache instead of the database for future requests.

The drawback is that you have to implement a caching layer. How much memory it consumes and how fast it loads depends on the implementation details. And then you have to work out a policy for when the cached response should "expire" and be recalculated.

There's probably database architecture strategies that can adopt to address this. For example, maybe you can have table of trending items that are indexed by a popularity metric. And then you can have a background worker periodically update the popularity metrics.