Dynamic Detection

Some of what ConfigDirector tells you is concluded from silence: a temporary config that your applications have stopped evaluating is ready to archive, and an old key left behind by a rename is removed once your applications stop using it. How long that silence has to last depends on how that config or flag is being used. A flag that is read on every app request and then goes for two entire days without an evaluation is almost certainly gone from the code. A flag read by a weekly job that goes a week without evaluations, is simply waiting for the next job run.

So instead of one fixed wait for everything, ConfigDirector gives each config its own wait, called its quiet window, based on how often it has been evaluated recently. A config that your applications read all the time gets a short window, and one read on a schedule gets a window long enough to cover the usual pause between runs, with room to spare. The window is worked out again every 30 minutes, so it follows changes in how your applications use the config. To see a temporary config's current quiet window once it has been evaluated, hover its status in the configs list.

An example

Take two temporary feature flags that have both been evaluated in production for months:

• new-checkout is read by the web app on every page load, many times a minute. Its quiet window is 4 days, the shortest allowed.
• invoice-layout-v2 is read only by a billing job that runs every Monday. A week without an evaluation is normal for it, so its quiet window is 14 days.

When the code that reads new-checkout is removed, the flag becomes Archive Ready 4 days after its last evaluation. invoice-layout-v2 becomes Archive Ready only after two weeks without an evaluation, so a single skipped run does not mark it ready to archive.

With one fixed wait of 4 days for both, invoice-layout-v2 would be marked ready to archive every Friday while the job still depends on it, and archiving it would leave the next Monday's run with its in-code default value.

Give each application its own app name

A flag is often read by more than one application, or by more than one component within an application. Say the web app also reads invoice-layout-v2 all day, every day, while the billing job keeps reading it every Monday. Give the web app and the job different app names when they initialize the ConfigDirector SDK. ConfigDirector can then tell them apart and see the two distinct usage patterns, so the flag keeps the 14-day quiet window that covers the weekly job. Even after the web app stops reading the flag, it stays In use for as long as the job keeps running.

Without different app names, the web app and the job would look like a single application to ConfigDirector. The job's evaluations then mix in with the web app's constant stream, the flag looks like one that is read all the time, and it gets the 4-day quiet window. Once the web app stops reading the flag, it would be marked ready to archive between the job's runs.

The setting is called appName in most SDKs, and each SDK's page shows where to set it.

Safety limits

Every quiet window is kept between a minimum and a maximum:

• The minimum is the shortest the window can be, however often the config is evaluated. It is a safety margin for uses that are easy to miss, such as a daily job inside the same application as busy web traffic, whose evaluations mix in with that traffic.
• The maximum is the longest the window can be, however rarely the config is evaluated. A config read only every few months, such as by a quarterly job, can become Archive Ready between runs, so check when it was last evaluated before you archive it.

Until a config has been evaluated for long enough to show its usual pace, its quiet window has a fixed length instead. A config first evaluated 3 days ago has a quiet window of 7 days, so it cannot be marked ready to archive until a week after that first evaluation.

Archive Ready explains which environments' evaluations count toward a config's quiet window.

Old keys

When you rename a config that is in use, its old key keeps working alongside the new one. ConfigDirector removes an old key once it has gone its quiet window without an evaluation in any environment, and your applications have evaluated a newer key since. The wait never starts before the rename, so every old key is kept for at least 35 days. If no newer key is ever evaluated, the old key stays. Old keys are checked twice a day.

The 35-day minimum covers jobs that run at least once a month. An old key read less often, such as by a quarterly job, can be removed between runs, so update those jobs to the new key before their next run.