Hello!
We have a new service we’d like to allow users to opt in (or out) of using. Let’s say we have 5000 customers, and ~5% of them we expect to opt into using this new service. This is something they can configure themselves. The “new service” vs the other is essentially just an origin change at this point.
Speed is important and we’re already using a Fastly’s CDN (a “VCL Service”) in front of these services.
We were considering using a dictionary + the Fastly API hooked up to our configuration backend to allow a customer control this behavior. Something like “in our admin interface, if the user chooses to opt-in to new service, on save send an API request to Fastly’s Dictionary API and add their unique customer ID as a key in the dictionary used by the VCL service” - fairly straightforward and certainly doable code wise, but it seems like the sort of thing that could be overloading / misusing the dictionary feature as Fastly has intended it.
Concerns I have include:
- Is it OK to frequently write / modify a dictionary via the API? We’re not talking about a TON of updates most likely (and we could always build in a batch system if needed)
- Are dictionaries volatile? If we write a customer ID to a dictionary, are there ever any situations where the item could be removed from the dictionary for any reason?
- If, at some point, 50% of our 5000 customers wanted to “opt in” to this service, we’d need to be creative with dictionary key / values and perhaps overload the keys in someway to allow for this many customers - as a default option, I imagine we’d store each customer id as a key or something like this.
We could do this in a Compute service + KV Store perhaps, but we are really hoping to keep this as much at the simple CDN layer.
Any thoughts would be much appreciated!