Polling Protocol Optimisation

[cjoy]

Context

Right now we're using ETags which is used by the server to determine whether or not to send back content. It's essentially a hash that's generated from an evaluated flagset. Essentially on the initial request, the client sends an empty ETag in the request header when retrieving the initial evaluated flagset. The server responds back with an ETag in the response header, that represents the current state of the evaluated flagset. On every subsequent request from the client to the server, the client uses the ETag provided by the server on the previous request.

Problem

Although this mechanism provides some sort of caching in a stateless manner, it's not very efficient. Everytime the hash sent from the client does not match the one on the server, we resent the entire flagset and start the dance all over again. We want to design a contract that will allow us to only send back the delta (i.e. changed flags) in a flagset. On the client, the delta will be merged with the client's existing flagset.

[its-rich]

Here are my inexperienced thoughts:

1. Have a hash for each flag, then all of the flags are transferred as a list to the server-side SDKs. The hash could be derived from the targeting configuration of the flag
2. If you wanted to keep the client SDKs to only sending GET requests, you could add a lot more infrastructure server-side. You could always cache users for an hour, so that when a flag's targeting configuration are updated, you could update the cached version then when the client-side SDK polls, it would see that it is out of date compared to the cached version.

• If this kind of approach is taken, you could then allow developers to specify how long they want these kind of users to be cached for, since there may be power users whose "time to live" TTL, should be shorter as the developers wish to test more experiments with these kind of users.

3. Alternatively could a publisher-subscriber pattern be better here? Since then there is minimal polling, as the server would be sending updates to the specified clients when necessary. You could also still have a similar polling approach if the client has been out of sync for lets say a week or is new.

I am also assuming the ideal scenario would be to only send the new flags to the client-side SDKs and then client side, their evaluated flagset would be merged with these new flags.

[cjoy]

I like the idea where we assign a version for each flag.

We could amortize the cost deriving the hash of a flag from its targeting configuration, by storing a version number on the flag itself (via the targeting table). Every time the targeting configuration of a flag is mutated, we just increment the version field.

This version number can be send to the client in the polling response. On every subsequent request, we can send back a subset of the original flagset that only contains the key and the version number of each flag. That way, the server can calculate what flags have changed and only send back the delta.