Agnostic cache strategy

Implementing strategy on the cache level using Flagship

For this strategy, the cache server run alongside a lightweight backend that synchronize with your Flagship configuration to provide feature flagging & experimentation abilities to the cache server.

How it works

Here is a big picture architecture of how the strategy works:

The typical flow for the Flagship cache architecture is the following:

1. A new visitor makes a request to a website resource
2. The request reaches the cache server
3. The cache server check if a cookie named fs-experiences exists
4. If the cookie exist the cache server use the campaign_id/variation_id combination as cache hash
5. If the combination has already been served to another visitor, the cache server returns the content directly
6. Otherwise, it makes a round trip to the application server to get the customized content
7. If the cookie doesn't exist, the cache server will send HEAD Request to a lightweight server dedicated to Flagship API that has predefined visitor ID and context and generate campaigns and variations that correspond the visitor.
8. The cache server receives the campaigns and variations and store the campaign_id:variation_id combination in a cookie named fs-experiences

Hashing mechanism

This implementation architecture makes use of the campaign_id:variation_id combination for the visitor as a hash for the caching system to know whether the cache is a hit or a miss.
This means that the cache will miss whenever a combination changes. This ensures the application is refreshed whenever the cache combination changes (either because of visitor ID context update or campaign update on the platform).

Caveats of this method

When doing any kind of customization (feature flagging or experimentation) on the cache level, you have to make compromise in order to keep the advantages of the caching architecture:

• This strategy rely on the cookie to get the campaign_id:variation_id combination that will later be checked whether it is cached or not, so if the client delete the cookie, we need to send the HEAD Request to the dedicated Flagship server to get the combination which can add couple of ms.
• The cache granularity will be a bit different than with the common caching mechanism. Instead of being cached per URL, the cache will be based on the campaign_id:variation_id combination of the visitor. This means that cache miss will occur more frequently, but still very rarely compared to all the visitors requests.
• This strategy require a separate dedicated server for Flagship API, which can consume some amount of CPU / RAM resources on top of your usual implementation. This should be taken into account when scaling your infrastructure

Links for the Flagship strategy

• Varnish strategy: https://github.com/flagship-io/flagship-varnish-strategy
• Nginx strategy: https://github.com/flagship-io/flagship-nginx-strategy