Abstract

We want to provide a proxy to users of GrowthBook who can deploy to their infrastructure which will take care of keeping the feature list updated in almost real time. To do that we can make use of webhooks. This will have the added benefit of all services calling GrowthBook API frequently.

Feature Requirements

The proxy needs to support both use case of polling based data fetching and webhook based data fetching. GB users should be able to select only the polling based or only the webhook or even be able to enable both if they wanted to.

Nice to have features

Every time there’s a new data, it’d be nice if we could send out an update to clients based on websocket. This would mean, with the combination of webhook based data and websocket, a change in feature config would reflect instantly.

Challenges

When using webhook, if the proxy is scaled out in any way (in a lot of situation people use minReplica: 2) webhook would require some shared state.

In addition to that, let’s say it’s running in both webhook and polling mode. Once we get a webhook, it shouldn’t rewrite the state with cached data from CDN if the CDN hasn’t refreshed yet.

Solving the challenges

To solve the shared state challenge, we can try one of the following

• Set a dependency on something small that doesn’t have to be Highly Available. Something like redis or a mqtt broker.
• Ask people to share volumes (not very nice) (What if they’re running on something like elastic beanstalk)
• Completely disable HA mode, only 1 instance can ever be running at any time (This is ridiculous, we can’t really do this)

To solve the problem of maybe data being out of date through CDN, we can try one of the following:

• Ask the growthbook team to invalidate the CDN cache when there are changes. (The problem with this is that we can only cache finite times for free)
• Ask the growthbook team to add a updated_at time in the feature query API and compare the data that way.
• Have a worker that fetches growthbook API in a polling fashion, in addition to that, it’s also subscribed to redis which let’s this worker know when there was a change and to ignore the data if the cache was hit on cloudfront and only take the data after that. This needs to be ironed out. There’s a age field which tells us how long ago the data was cached. We compare age to the last time redis published and we know if we need to replace or ignore the new data.

Proposal

I propose to declare dependency on non HA redis. This will help by doing two things. The pubsub mechanism of redis will allow us to do websockets more easily. It will also solve the problem of shared state as well as it makes it easy to solve the CDN cache problem.