When to use polling and streaming in launch darkly

Question

I have started using launch darkly(LD) recently. And I was exploring how LD updates its feature flags.

As mentioned Here, there are two ways.

1. Streaming
2. Polling

I was just thinking which implementation will be better in what cases. After a little research about streaming vs polling, It was found Streaming has the following advantages over polling.

• Faster than polling
• Receives only latest data instead of all the data which is same as before
• Avoids periodic requests

I am pretty sure all of the above advantages comes at a cost. So,

1. Are there any downsides of using streaming over polling?
2. In what scenarios polling should be preferred? or the other way around?
3. On what factors should I decide whether to stream or poll?

Answer 1

Streaming

Streaming requires your application to be always alive. This might not be the case in a serverless environment. Furthermore, a streaming solution usually relies on a connection that is always open in the background. This might be costly, so feature flag providers tend to limit the number of concurrent connections you can keep open to their infrastructure. This might be not a problem if you use feature flags only in a few application instances. But you will easily reach the limit if you want to stream feature flag updates to mobile apps or a ton of microservices.

Polling

Polling sounds less fancy, but it's a reliable & robust old-school pattern that will work in almost all environments.

Webhooks

There is a third option too: webhooks. The basic idea is that you create an HTTP endpoint on your end and he feature flag service will call that endpoint whenever a feature flag value update happens. This way you get a "notification" about feature flag value changes. For example ConfigCat supports this model. ConfigCat can notify your infrastructure by calling your webhooks and (optionally) pushing new values to your end. Webhooks have the advantage over streaming that they are cheap to maintain, so feature flag service providers don't limit them as much (for example ConfigCat can give you unlimited webhooks).

How to decide

How I would use the above 3 option really depends on your use-case. A general rule of thumb is: use polling by default and add quasi real-time notifications (by streaming or by webhooks) to the components where it's critical to know about feature flag value updates.

Answer 2

In addition to @Zoltan's answer, I Found the following from LaunchDarkly's Effective Feature management E book (Page 36)

In any networked system there are two methods to distribute information.

Polling is the method by which the endpoints (clients or servers) periodically ask for updates. Streaming, the second method,is when the central authority pushes the new values to all the end‐points as they change.Both options have pros and cons.

However, in a poll-based system, you are faced with an unattractive trade-off: either you poll infrequently and run the risk of different parts of your application having different flag states, or you poll very frequently and shoulder high costs in system load, network bandwidth, and the necessary infra‐structure to support the high demands.

A streaming architecture, on the other hand, offers speed advantages and consistency guarantees. Streaming is a better fit for large-scale and distributed systems. In this design, each client maintains along-running connection to the feature management system, which instantly sends down any changes as they occur to all clients.

Polling Pros:

• Simple
• Easily cached

Polling Cons:

• Inefficient. All clients need to connect momentarily, regardless of whether there is a change.

• Changes require roughly twice the polling interval to propagate to all clients.

• Because of long polling intervals, the system could create a “split brain” situation, in which both new flag and old flag states exist at the same time.

Streaming Pros:

• Efficient at scale. Each client receives messages only when necessary.

• Fast Propagation. Changes can be pushed out to clients in real time.

Streaming Cons:

• Requires the central service to maintain connections for every client

• Assumes a reliable network

For my use case, I have decided to use polling in places where I don't need to update the flags often(long polling interval) and doesn't care about inconsistencies (split-brain) .

And Streaming for applications that need immediate flag updates and consistency is important.