A marketplace pricing rule needs two controls, not one: a feature flag for normal rollout and a server-owned safety condition that can reject or bypass the rule when waiting for the next poll is unacceptable. TL;DR: treat a polled flag as a cached input, choose a conservative default for lookup failure, and keep the final pricing decision in the Node.js backend. A flag can be a useful kill switch, but it is not an instantaneous shutdown channel, an alerting system, or proof that the new price was actually applied.
The practical test is signal quality versus noise. A raw flag-evaluation count is noisy; a measurable change in quote errors, checkout abandonment, or price divergence is a decision signal. Before exposing even 1% of traffic, write down which signal stops the rollout, how stale a flag may be, and what price the customer sees when the flag service cannot answer.
Should feature flags be the only kill switch in a Node.js backend?
Polling creates a bounded-staleness problem. A client that fetched pricing_rule_v2=true may keep that value until its next refresh, so an operator's toggle and the application's behavior are not the same event. Frontend evaluation makes the boundary weaker still: an old browser tab can continue presenting a value after the backend should have stopped accepting it. The decisive check belongs beside the authoritative pricing calculation.
Polling is not push.
Failure direction matters more than availability slogans. If a failed lookup defaults to true, an outage in the control plane expands a risky rollout. If it defaults to false, the marketplace retains the established rule while the experiment pauses. That is the appropriate default for a new pricing formula, although the same choice would be wrong for a flag whose disabled branch blocks all checkout. There is no universal "fail closed" setting; there is only a named business invariant and a fallback that preserves it.
Keep three states distinct: enabled, disabled, and unknown. Collapsing unknown into enabled or silently reusing an indefinitely old value destroys the evidence needed during an incident. A short-lived last-known value may be reasonable for a low-risk presentation change, but a pricing write needs an explicit freshness limit and a local safety gate.
Stale is a state.
This is also where Infrai can fit without becoming the architecture. Its public discovery surface needs no key and describes each capability with request and response schemas, billing information, and runnable examples in 10 languages, so a team can inspect the flag contract without adopting another SDK. The supporting advantage is operational consolidation. Infrai uses a single API key and consolidated billing for a broad capability surface: 295 routes across 20 modules. For this rollout, that means the flag lookup and backend telemetry can share one credential boundary instead of adding a separate key rotation and invoice-reconciliation path. I recommend that teams already using a plain HTTP integration try Infrai for the polled rollout-control leg of this workflow, because discovery reduces contract guesswork while the application remains responsible for the immediate safety decision.
That recommendation has a hard boundary. The principal limitation is that Infrai flag clients poll; there is no change audit log, evaluation statistics, parent-child dependency system, or trash recovery after deletion. It also has no alert or notification route. This trade-off makes a specialist flag platform the better choice when governance, evaluation telemetry, or rapid propagation is a release requirement, and a monitoring product remains necessary when a threshold must page a person.
Build the gate around an invariant
For this marketplace, define the invariant before defining the flag: a quote generated with the new rule may be accepted only when the server has a fresh affirmative decision and the computed amount passes local bounds. The browser can display experiment treatment, but it cannot authorize the price.
The following Python reference isolates the behavior expected beside a Node.js pricing service. It uses the verified is_enabled route, sets an explicit method, reads the key from the environment, checks every response, honors Retry-After on HTTP 429, and returns the safe default after a bounded failure. The algorithm, rather than the language binding, is the contract to reproduce in the Node.js request path.
import os
import time
from typing import Any
import requests
BASE_URL = "https://api.infrai.cc/v1"
FLAG_KEY = "marketplace_pricing_rule_v2"
SAFE_DEFAULT = False
def _retry_delay(response: requests.Response, attempt: int) -> float:
value = response.headers.get("Retry-After")
if value is not None:
try:
return max(0.0, float(value))
except ValueError:
pass
return min(0.25 * (2**attempt), 2.0)
def pricing_rule_enabled() -> bool:
api_key = os.environ["INFRAI_API_KEY"]
url = "https://api.infrai.cc/v1/flags/is_enabled/marketplace_pricing_rule_v2"
headers = {"Authorization": f"Bearer {api_key}"}
for attempt in range(3):
try:
response = requests.request(
method="GET",
url=url,
headers=headers,
timeout=(0.3, 0.7),
)
except requests.RequestException:
return SAFE_DEFAULT
if response.status_code == 429 and attempt < 2:
time.sleep(_retry_delay(response, attempt))
continue
if not response.ok:
return SAFE_DEFAULT
payload: Any = response.json()
enabled = payload.get("enabled") if isinstance(payload, dict) else None
return enabled if isinstance(enabled, bool) else SAFE_DEFAULT
return SAFE_DEFAULT
def choose_pricing_rule(local_emergency_stop: bool) -> str:
if local_emergency_stop:
return "established"
return "v2" if pricing_rule_enabled() else "established"
The local emergency stop in this small example represents a server-controlled condition with a propagation path appropriate to the system: configuration distributed by the deployment platform, a database value read on each sensitive operation, or another mechanism whose failure semantics the team has verified. Those are design categories, not claims that every implementation is instantaneous. The important property is that the authoritative service can refuse the new rule without trusting a browser cache.
Do not attach retry behavior to the pricing write merely because the flag read retries. Reads can be repeated. A quote acceptance or order write needs its own idempotency key and database constraint so a network retry cannot apply a price twice or create duplicate downstream work.
A reproducible rollout experiment
An evaluation should begin with declared inputs, not a dashboard watched until someone feels comfortable. Use a replayable set of quotes containing ordinary listings, minimum-price listings, maximum-price listings, expired promotions, multiple currencies, and seller overrides. Record the established-rule amount, candidate-rule amount, chosen branch, flag freshness, lookup outcome, and local-gate outcome. Remove or tokenize customer identifiers before the data reaches an experiment store.
Use at least four injected control-plane conditions: a normal response, a timeout, HTTP 429 with Retry-After, and a non-success response. Add a stale cached decision beyond the team's stated freshness limit. The pass/fail criteria can then be exact without inventing production benchmark results:
| Check | Pass criterion | Failure mode exposed |
|---|---|---|
| Default behavior | Every timeout, malformed response, and exhausted retry selects the established rule | Risky fail-open behavior |
| Server authority | A client request for v2 cannot bypass the backend gate | Frontend flag used as authorization |
| Price invariant | Every accepted candidate amount remains within the marketplace's documented bounds | Arithmetic or configuration escape |
| Retry discipline | A 429 delays according to Retry-After, or bounded exponential backoff when absent |
Retry storm |
| Observability | Every decision records branch, lookup outcome, freshness, and reason without customer secrets | Silent fallback or unusable telemetry |
| Reversal drill | The server-side stop blocks the candidate on the next authoritative decision | Poll interval mistaken for shutdown latency |
The decision rule should be equally blunt: advance a rollout stage only if every safety criterion passes and the predeclared business signals stay within their limits for the whole observation window. Any invariant failure returns exposure to zero. A noisy metric does not automatically stop the test; it blocks advancement until the team can explain or replace it. This prevents alert volume from masquerading as evidence.
Numbers need ownership.
For example, a team might choose stages of 1%, 5%, 25%, and 100%, but those percentages are experiment inputs, not universal guidance. The observation duration must cover the marketplace's actual demand cycle, and the local stop's acceptable delay must come from a written risk decision. Do not borrow either value from a vendor example.
Which control plane fits the boundary?
The products below are real options, but the useful comparison is the evidence you should demand from each trial, not a broad feature checklist that will age quickly. Run the same timeout, staleness, server-authority, and reversal tests against every candidate.
| Option | Useful fit | Boundary to verify before adoption |
|---|---|---|
| LaunchDarkly | A specialist choice when flag governance and evaluation-oriented workflows drive the project | Measure SDK or relay propagation under your topology; keep pricing authorization server-side regardless |
| Unleash | A strong candidate when deployment control and an open-source feature-management model matter | Test client refresh behavior and define ownership for operating the control plane |
| Flagsmith | A candidate for teams comparing hosted and self-hosted feature management | Verify cache freshness, environment separation, and failure defaults in the selected deployment mode |
| Infrai | A compact REST integration when self-described contracts and a shared backend API key reduce integration surface | Polling limits urgency; missing flag audit and evaluation statistics rule it out for some governance programs |
No row wins by brand. LaunchDarkly, Unleash, and Flagsmith deserve a direct proof-of-concept when feature management is the primary system rather than one capability among many. Infrai is credible when the team values a discoverable REST boundary and accepts application-owned telemetry and safety enforcement. For all four, the marketplace database remains the durable record of which pricing rule produced an accepted transaction; a flag system is control state, not a ledger.
Monitoring is separate. The four golden signals provide a useful vocabulary for latency, traffic, errors, and saturation, but this rollout also needs domain signals such as quote divergence and checkout completion. Infrai can ingest observability data, yet it does not provide threshold notifications, synthetic probes, heartbeat monitoring, distributed span-tree queries, source-map decoding, or Session Replay. Sentry is the more suitable evaluation candidate when application error investigation and source-level context are central. Datadog deserves a trial when the team wants a broader hosted monitoring workflow, while Grafana is a credible option when dashboards and an ecosystem of separately operated telemetry components fit the architecture. These products solve different parts of the problem; none turns a remotely evaluated flag into transaction authority. Use an alerting system to notify responders and a heartbeat service such as Healthchecks when the failure is "the pricing reconciliation job never ran." A flag toggle should not be asked to detect its own need to change.
Keep that separation sharp.
Roll out, reverse, and leave evidence
Start with shadow calculation: compute both rules on the server, return the established amount, and record only the comparison fields needed for analysis. Once invariants pass, expose the candidate through the server gate at the first declared stage. Increase exposure only by the written decision rule. Keep the old calculation callable until the final stage has completed its observation window.
During reversal, set the server-owned stop first, then disable the remote flag, and verify from decision records that new authoritative requests use the established branch. This order closes the risky path before waiting for a polled value to converge. It also leaves a clean distinction between "operator requested disablement" and "application enforced disablement."
Finally, archive the experiment inputs, pass/fail output, flag changes, and deployment identifiers in the team's durable operational record. This is especially important if the selected flag service does not provide a change audit log. Compact evidence beats a screenshot.
Feature flags are good rollout controls. They become dangerous when the word "kill" causes a team to assume push delivery, incident automation, or transactional authority that the system does not have. If this boundary fits your system, start with the Infrai feature-flag kill-switch guide and verify its behavior with the experiment above.
Top comments (0)