Request Caching for Symfony 3 application with > 1 million combination of query parameters

Question

We have a REST Webservice build with Symfony3 and PHP7. The application is served via Nginx and PHP-FPM.

The Webservice returns a list of products. Products inside the list are filtered by attributes. The result would be the list with a subset of its products, filtered by attributes. Those attributes are send via GET parameters in the url. For now there are 4 parameters resulting in around 1 million combination of Urls per product. Product data changes constantly.

Example List before filtering:

{
  name: "list1",
  products: [
    {
     name: "product1"
    },
    {
     name: "product2"
  ]
}

Example List after filtering:

{
  name: "list1",
  products: [
    {
     name: "product2"
  ]
}

Example API resource: /list?slug=list1&filter1=foo&filter2=bar&filter3=baz

In order to improve performance we want to cache requests with Nginx fastcgi_cache. The response would be cached with a cache key that equals the request url.

When we cache the responses for 1 hour we need to invalidate cache entries when data of a product changes. So we need to invalidate all cache entries that include that product.

So what I could do is, I could find out all Lists that include the product. And than create every combination of filters and create all possible urls for the list. Then invalidate those entries.

I think that would need very much resources to invalidate/refresh the cache.

How to properly cache and properly invalidate the cache in such situations?

Similar unanswered question Should processing/filtering be performed client side or server side for catalog based apps

Answer 1

Caching isn't a performance improvement, it a way to make bad performance more tolerable, and it only works if the data is staying the same and its being used a lot. Its generally better to cache the full result set and then filter on demand, this allows for minimal use of memory and maximum use of the cached results. You could collect data and analyze which combinations are most popular and cache those as well if the filtering itself is the slow part, but be careful how far you go down this path the more you fragment your cache the less useful it becomes.

As far as invalidating a cache when the data behind it changes, this is antithetical to using caching. Stale/potentially stale results are a drawback to caching, this is mitigated by choosing proper times to expire the cache either on a set or rolling schedule. Its possible to poll for changes since the cache was made, but this will likely eliminate most of your performance gain unless getting the product list is extremely slow. If you control how products are added/changed you could modify that process to expire the cache, this is a better solution than polling but may limit the usefulness of caching if product updates are too frequent.