Hootsuite wrote a blog post on doing this sort of thing with Consul: <a href="http://code.hootsuite.com/distributed-configuration-management-and-dark-launching-using-consul/" rel="nofollow">http://code.hootsuite.com/distributed-configuration-manageme...</a> (The post itself is over a year old but the concepts still apply today)<p>You can use the Go API client[1] to make this possible from Go. I'm biased as I work for HashiCorp but just wanted to add a server-based option to the mix if a local BoltDB won't work for you.<p>[1]: <a href="https://github.com/hashicorp/consul/tree/master/api" rel="nofollow">https://github.com/hashicorp/consul/tree/master/api</a>
The API usage is very inefficent when using it for every feature-flag in an app. If you could call the API with user-ID and group and it returns all the feature-flags active there would be a far greater use-case.
Rollout flags are IMHO best implemented when they are pushed to the machines that need to read them by a technology like zookeeper. Pushed updates are then cached in memory by the machines receiving the updates and can be queried in the hotpath without having to worry about cache invalidation and the extra overhead of network calls.
We've been working on something very similar at work. I don't know if this solution scales very well, as others have mentioned here. One thing that seems unusual to me is the decision to use a POST request instead of GET for the /access endpoint.