Proposing a mode: flags provider as startup-critical for always-on, high-availability services. #241
Replies: 2 comments
-
Hey @dominikhaska, good question! We recently introduced a spec change that supports a blocking provider. This will allow you to wait for the provider to start up continuing. It's also possible to use the asynchronous set provider call and subscribe to the provider-ready event. This lets you ensure the provider has started up properly before serving traffic. Here's the PR to add It's also possible to subscribe to provider error events. This occurs when a provider loses connectivity with the source of truth. It may be useful in some scenarios to avoid sending requests to services with stale flags. |
Beta Was this translation helpful? Give feedback.
-
Problem solved |
Beta Was this translation helpful? Give feedback.
-
Should we introduce an additional mode where the flags provider is set as startup-critical for always-on services with high availability configurations?
Let’s assume we have a distributed service and a new location or more job in the existing environment is needed.
In some cases it’s better to wait for flags provider to be ready for flag evaluation than to start serving with unwanted flags values (even defaults are not always good).
Example:
If service starts working before flags configs are ready and then those flags start changing as config arrives service user will observe flags flickering. It's better to not use this service, restart it or spawn again than use without valid flags.
Of course this problem is for always connected services when we can rely on flags config delivery to be highly available
Would it be possible to have 2 modes of operation?
Flags provider as:
Beta Was this translation helpful? Give feedback.
All reactions