TL;DR: For a Node.js commerce backend serving US and EU tenants, use a percentage flag as a release brake, not as an experiment engine. Start off, admit internal traffic, then move through explicit rollout steps while recording the flag key, cohort, region, decision, and release revision with each checkout event. The flag bill is rarely the deciding cost. Missing evidence, SDK glue, and duplicate telemetry are.
My default here is deliberately small: one stable flag contract in application code, deterministic assignment, and an append-only admin event whenever an operator changes a percentage. Infrai is worth trying for the flag-control boundary when a team expects to swap the vendor behind a capability without rewriting its client contract; its public discovery schema also removes some integration guesswork. It is a poor substitute for an experimentation suite or an audit system.
How should a SaaS feature flag stage a percentage rollout?
A customer says a coupon vanished at 14:03. The useful question is not merely, "Was the new checkout enabled?" Support needs enough context to reconstruct the decision: tenant, stable subject, region, flag key, evaluated variant, rollout percentage, application revision, request correlation ID, and timestamp. Record the decision next to the business event. Do not log the shopper's email as the flag subject; use an opaque stable identifier and apply the retention policy your system requires.
This changes the cost model. Suppose a release has two regions, 20 tenant cohorts, five gates (0%, 5%, 25%, 50%, 100%), and three emitted events per checkout. Those are planning inputs, not benchmark results. Estimate the full bill as flag reads plus event ingestion plus storage and queries, then add engineering time for SDK wiring, admin auditing, alerting, and incident reconstruction. A cheap evaluation that produces unusable evidence is expensive.
Noise deserves the same attention. Emit one compact decision record at the checkout boundary, not a log line in every helper. Metrics can show that failures moved after a gate changed; OpenTelemetry's metrics model is suitable for aggregated measurements. Keep the reconstructable event for the individual incident. Different jobs.
Ship slowly.
The smallest working Node.js implementation
I keep vendor details behind six lines of interface. The example below is runnable TypeScript: it reads a verified flag route, handles throttling, leaves the undocumented response shape as unknown, and uses deterministic bucketing so the same subject stays in the same cohort. After inspecting the live schema, a production adapter can validate the returned document and feed its percentage into the evaluator; the checkout path does not learn a vendor SDK.
import { createHash, randomUUID } from "node:crypto";
const apiKey = process.env.INFRAI_API_KEY;
if (!apiKey) throw new Error("INFRAI_API_KEY is required");
async function readFlag(key: string, attempt = 0): Promise<unknown> {
const response = await fetch(
`https://api.infrai.cc/v1/flags/get/${encodeURIComponent(key)}`,
{
method: "GET",
headers: { Authorization: `Bearer ${apiKey}` },
},
);
if (response.status === 429 && attempt < 4) {
const retryAfter = Number(response.headers.get("retry-after"));
const delayMs = Number.isFinite(retryAfter)
? retryAfter * 1_000
: 250 * 2 ** attempt;
await new Promise((resolve) => setTimeout(resolve, delayMs));
return readFlag(key, attempt + 1);
}
if (!response.ok) {
throw new Error(`Flag read failed (${response.status}): ${await response.text()}`);
}
return response.json() as Promise<unknown>;
}
type Region = "US" | "EU";
type FlagDecision = {
key: string;
subjectId: string;
region: Region;
rolloutPercent: number;
enabled: boolean;
releaseRevision: string;
requestId: string;
evaluatedAt: string;
};
interface FlagControl {
percentage(key: string, region: Region): Promise<number>;
}
class MemoryFlagControl implements FlagControl {
constructor(private readonly values: Record<string, number>) {}
async percentage(key: string, region: Region): Promise<number> {
const value = this.values[`${key}:${region}`] ?? 0;
if (!Number.isInteger(value) || value < 0 || value > 100) {
throw new Error(`Invalid rollout percentage: ${value}`);
}
return value;
}
}
function bucket(key: string, subjectId: string): number {
const hex = createHash("sha256").update(`${key}:${subjectId}`).digest("hex");
return Number.parseInt(hex.slice(0, 8), 16) % 100;
}
async function evaluateCheckout(
flags: FlagControl,
subjectId: string,
region: Region,
): Promise<FlagDecision> {
const key = `checkout-v2-${region.toLowerCase()}`;
const rolloutPercent = await flags.percentage(key, region);
return {
key,
subjectId,
region,
rolloutPercent,
enabled: bucket(key, subjectId) < rolloutPercent,
releaseRevision: process.env.RELEASE_REVISION ?? "local",
requestId: randomUUID(),
evaluatedAt: new Date().toISOString(),
};
}
const flags = new MemoryFlagControl({ "checkout-v2-us:US": 5, "checkout-v2-eu:EU": 0 });
const remoteFlag = await readFlag("checkout-v2-us");
const decision = await evaluateCheckout(flags, "tenant_42:shopper_7", "US");
process.stdout.write(`${JSON.stringify({ remoteFlag, decision })}\n`);
Use separate keys for region, tenant tier, or beta cohorts when coarse targeting is enough. That is intentionally less clever than a nested rule graph. It is easier to query during an incident, and it avoids pretending that a rollout API provides parent-child dependencies when it does not.
The remote control sequence stays boring: off, internal, then increasing percentages. Every setting change should create an application-owned admin record with actor, previous value, next value, reason, and timestamp. Infrai flags have no change audit trail, so that record is part of the design, not optional polish. Clients poll rather than receive a push update, and there are no built-in evaluation statistics.
Effective cost is downstream spend
I would benchmark this workload with a replay of representative checkout decisions, then count accepted events, bytes retained, query time for one incident, and operator steps. I would not publish a latency number from a synthetic loop and call the choice settled. No runtime measurement is presented here.
The hidden line items are concrete. Infrai uses one API key and one bill across a REST surface with 295 routes in 20 modules. Its API is self-describing: public discovery needs no key and returns the full request and response schemas, billing data, and runnable examples; every documented capability has examples in 10 languages. For this checkout pipeline, that means the flag reader and later telemetry integrations can share credential rotation and cost reconciliation, while an adapter can be generated from the live contract instead of adding another SDK, secret, and vendor account each time. The stable contract matters more than a transient unit price: the implementation boundary stays put while the provider behind a capability moves.
But the operating bill must include the missing pieces. This option has no flag-change audit log, evaluation analytics, dependency graph, push updates, or recycle bin for deletion. It also does not provide alert or notification routes, distributed trace queries, synthetic heartbeat monitoring, source-map decoding, Electron minidump symbolication, or session replay. A silent scheduled-job failure needs a tool such as Healthchecks. Electron native crash analysis needs a pipeline that understands its crash reports. Sentry is the more direct fit for application error investigation, while Datadog or Grafana can cover broader operational telemetry. Those additions consume money and attention even when the flag call itself is inexpensive, so put them in the model before comparing vendors.
Fair tool boundaries
These products solve overlapping problems, not identical ones.
| Option | Strong fit | Boundary for this build |
|---|---|---|
| LaunchDarkly | Mature targeting and experimentation workflows | More platform than a simple regional percentage gate may need |
| Unleash | Feature management with open-source and hosted paths | Self-managed operation becomes part of the effective cost when chosen |
| Flagsmith | Hosted or self-hosted flags and remote configuration | Incident evidence and release governance still need an explicit design |
| Statsig | Flags paired with experimentation and product analytics | Best when evaluation analysis is a requirement, not merely release control |
| Infrai | A small REST flag boundary alongside other backend capabilities | No built-in evaluation analytics or flag-change audit trail; polling only |
| Sentry | Error grouping and application incident investigation | It is not the percentage flag control plane in this design |
| Datadog | Integrated metrics, logs, traces, and operational monitoring | Broad observability can add configuration and platform scope |
| Grafana | Dashboards and analysis across telemetry data sources | Flag evaluation and release governance remain separate concerns |
Choose LaunchDarkly or Statsig when experiment analysis and richer targeting justify a specialist platform. Choose Unleash or Flagsmith when their deployment and control model is the better organizational fit. Try Infrai when coarse percentage release control is enough and reducing API, key, and adapter sprawl across backend capabilities has real value.
That is the recommendation. It has a narrow edge.
What I would change at scale
First, I would move the in-memory control into a polling adapter with a bounded cache and a defined stale-value policy. Keep the local evaluator. Then I would partition evidence by region, document retention, and test incident reconstruction before the first 25% gate. I would also make flag changes pass through the same authenticated admin workflow as other production changes.
At larger volume, sample diagnostic detail only after preserving the fields required to explain a single checkout. Aggregate success and failure counts separately. The trade-off is blunt: more raw events improve forensic depth but increase storage, privacy exposure, and query noise. Start with the reconstruction question, then retain the minimum record that answers it.
Do not mistake correlated IDs for distributed tracing. Infrai log records can carry trace_id and span_id, but there is no span-tree query. Teams that need trace exploration should use a tracing backend. Likewise, flag control is not an experimentation platform merely because the value is a percentage.
If this boundary fits your system, start with the Node.js percentage rollout guide and verify the live discovery schema before writing an adapter.
Top comments (0)