Node.js Feature Flags — Fallback Defaults, Caching, and 60-Second Polling

When employing Node.js feature flags, it is crucial to prioritize fallback defaults and caching to enable the notification worker to make secure decisions without relying on the flag service. In an edtech rollout, this entails setting a disabled default in the code, utilizing a short-lived last-known value, and establishing a polling interval based on the rollback deadline.

In essence, the risky delivery path should be set to false by default, with polling performed outside of the delivery loop. Caching of data should only be accepted within a specified freshness window, after which the code default should be utilized as a fallback.

The dangerous design involves a network read occurring in the hot path. Initially, a class reminder is presented to the worker, which subsequently requests the provider_v2. Subsequently, the delivery path becomes dependent on two services rather than just one. In the event of a slow or failed flag request, the reminder may be delayed, even though the established provider is functioning optimally.

To counteract this dependency, the delivery path should instead read a local snapshot synchronously. A background poller then refreshes this snapshot.

If the process has never successfully completed a valid poll, it should utilize the default compiled alongside the decision. In this scenario, false ensures that reminders continue to follow the established provider. Defaults serve as executable rollback policies. The cache operates differently; a cached true indicates that the experimental provider was enabled at an earlier time, but it does not guarantee that true remains safe indefinitely.

Therefore, three states should be modeled: fresh value, stale value, and no valid value. Fresh data can drive delivery, while stale or absent data should resolve to the code default once the declared freshness window expires.

For a rollback budget of 60 seconds, a practical starting policy is a 15-second poll interval and a 45-second maximum cache age. These figures represent design inputs rather than measured latency, leaving room for a missed poll while preventing an old true value from persisting indefinitely. With four Node.js processes, polling would be necessary unless the deployment coordinates among them, resulting in increased request volume based on the process count.

Polling is the sole client refresh model for Infrai flags. However, it lacks a flag-change audit log, evaluation statistics, parent-child dependency model, or recycle bin for deleted flags. A release checklist may suffice for a limited number of flags but should not replace governance when multiple individuals can alter production behavior. Ultimately, rollback should be designed as a state machine, not a simple Boolean value.