jkodumal

There's VSCO, Fluid, Roofstock, LaunchDarkly, and Uber coming soon. There's probably a few more great companies that I'm forgetting.

Fun fact-- it was started by one the founders of HipChat.

That's mostly right. We don't use ES as a primary datastore, though.

I mentioned this briefly in the article, but we thought about doing something with Lambda + API Gateway. But doing the math, 5k RPS pushed through API Gateway is about $1500 daily just to authenticate.

We had a lot of operational experience with Mongo from our previous jobs at Atlassian, and started out storing almost everything in Mongo. As we scaled out, we migrated all of our high volume data into other stores-- analytics into DynamoDB, searchable data into ElasticSearch, etc.

The last remaining piece is our core data, and there's no strong push to move it out of Mongo.

I think it depends on the workload. Serving 4.6k static pages per second, cached on a CDN, is not too difficult. However, handling an analytics workload of 4.6K RPS is a little harder.

I was being cheeky :)

Events are stored in DynamoDB. We use mongo for "core" data like accounts, feature flags, etc, but none of the high throughput stuff touches MongoDB.

For temporary feature flags, we try to clean up as soon as possible. As part of the rollout plan for a new feature, we'll have defined what metrics we're trying to achieve, and once we're confident that we've met those marks, we clean up the flag.

We eagerly create "cleanup branches" and corresponding pull requests to remove a flag-- that front-loads the cleanup work and means we aren't context switching back to try and remember how to clean up a flag.

Also, we've found that in practice flags are usually independent-- testing permutations of flags shouldn't typically be necessary. People usually take an analogous shortcut with feature branches-- we test branches in isolation but don't usually re-test after merging.

Our goal is to build a developer-focused platform that gives teams the ability to adopt feature flags as a core part of their dev cycle-- including pretty much all of the use cases described in Fowler's article (ops, permissioning, etc.). Many of our customers are not using us for A/B testing at all.

re: conditionals, DI: our SDKs focus on the base technique (flags based on conditionals), but it's possible to wrap that core with higher-level approaches like DI, etc. We're considering going down that path, but where it makes sense to do so, and not have to re-implement higher-level wrappers for every framework out there. So, e.g.-- in Ruby, I can see us providing higher-level APIs specific to Rails.

Dependent feature flags are also an interesting problem-- we don't have a solution to that yet, but we do spend a lot of time thinking about feature flags, and I hope we'll have something on that front soon :)