Delivering feature flags with lightning speed and reliability has always been one of our top priorities at Split. We’ve continuously improved our architecture as we’ve served more and more traffic over the past few years (We served half a trillion flags last month!). To support this growth, we use a stable and simple polling architecture to propagate all feature flag changes to our SDKs.
At the same time, we’ve maintained our focus on honoring one of our company values, “Every Customer”. We’ve been listening to customer feedback and weighing that feedback during each of our quarterly prioritization sessions. Over the course of those sessions, we’ve recognized that our ability to immediately propagate changes to SDKs was important for many customers so we decided to invest in a real-time streaming architecture.
Our Approach to Streaming Architecture
Early this year we began to work on our new streaming architecture that broadcasts feature flag changes immediately. We plan for this new architecture to become the new default as we fully roll it out in the next two months.
While real-time streaming using SSE will be the default going forward, customers will still have the option to choose polling by setting the configuration on the SDK side.
Streaming Architecture Performance
Running a benchmark to measure latencies over the Internet is always tricky and controversial as there is a lot of variability in the networks. To that point, describing the testing scenario is a key component of such tests.
We created several testing scenarios which measured:
- Latencies from the time in which a feature flag (split) change was made
- The time the push notification arrived
- The time until the last piece of the message payload was received
We then ran this test several times from different locations to see how latency varies from one place to another.
In all those scenarios, the push notifications arrived within a few hundred milliseconds and the full message containing all the feature flag changes were consistently under a second latency. This last measurement includes the time until the last byte of the payload arrives.
As we march toward the general availability of this functionality, we’ll continue to perform more of these benchmarks and from new locations so we can continue to tune the systems to achieve acceptable performance and latency. So far we are pleased with the results and we look forward to rolling it out to everyone soon.
Choosing when Streaming or Polling is Best for You
Both streaming and polling offer a reliable, highly performant platform to serve splits to your apps.
By default, we will move to a streaming mode because it offers:
- Immediate propagation time when changes are made to flags.
- Reduced network traffic, as the server will initiate the request when there is data to be sent (aside from small traffic being sent to keep the connection alive).
- Native browser support to handle sophisticated use cases like reconnections when using SSE.
In case the SDK detects any issues with the streaming service, it will use polling as a fallback mechanism.
In some cases, a polling technique is preferable. Rather than react to a push message, in polling mode, the client asks the server for new data on a user-defined interval. The benefits of using a polling approach include:
- Easier to scale, stateless, and less memory-demanding as each connection is treated as an independent request.
- More tolerant of unreliable connectivity environments, such as mobile networks.
- Avoids security concerns around keeping connections open through firewalls.
Streaming Architecture and an Exciting Future for Split
We are excited about the capabilities that this new streaming architecture approach to delivering feature flag changes will deliver. We’re rolling out the new streaming architecture in stages starting in early May. If you are interested in having early access to this functionality, contact your Split account manager or email support at email@example.com to be part of the beta.
To learn about other upcoming features and be the first to see all our content, we’d love to have you follow us on Twitter!
Stay up to date
Don’t miss out! Subscribe to our digest to get the latest about feature flags, continuous delivery, experimentation, and more.
The increased usage of feature flags and canary releases (also “canary deployments”) in software development has had a tremendous impact on the overall release process for software companies globally. These canaries and feature flags allow you to test your features in production , convert your monolith to microservices, perform A/B…
To understand how businesses can begin using feature flags, let’s look at a typical case of an organization evolving a continuous delivery system using feature flagging from the ground up. By analyzing a system taking shape, we can identify some of the common mistakes that software development teams make and…
As companies implement more innovative practices, they typically realize the faults of using an imperfect environment, like staging. Staging environments are expensive and they often do not match the behavior of production which leads to faulty test results. They also don’t provide any confidence that your features are working before…