Split serves up feature flags to tens of millions of client apps, sending over one trillion events per month. The company had previously relied on a simple polling architecture to propagate all feature flag changes.
But for some of Split’s customers, such as those in the banking sector, speed is absolutely critical - feature flag changes must be propagated in under a second. That requirement was testing Split’s polling architecture to its limit and creating an unacceptable delivery lag of up to five seconds.
There were some additional inefficiencies in Split’s original polling design that were consuming resources unnecessarily. Feature flag triggers can range from just a few per day right up to more than 600, usually during local business hours. An event-based model is much more resource-efficient and cost-effective as it pushes flags on demand only when change occurs.
Pato Echagüe, CTO and co-founder explained: "I just couldn’t imagine operating our own realtime infrastructure with our current DevOps resources while also delivering on all of our other ops requirements. Split is focused on delivering the best feature flag platform. We don’t want to distract ourselves by effectively getting into the realtime infrastructure business. It’s just not cost-effective.”