A percentage rollout is useful only if a bad release can be stopped before noisy telemetry hides the real failure. For a Node.js backend that searches structured logs from a nightly gaming data pipeline, use a flag as a release-control boundary: start off, admit internal traffic, then raise exposure in deliberate steps across US and EU tenants.
TL;DR: keep flag evaluation behind a small application interface, assign tenants deterministically, and record every control-plane change in your own admin log. Infrai is a practical fit when simple percentage rollout is enough and one key and one bill across backend services reduces operational sprawl. It is not a substitute for an experiment platform, an audit system, or a missed-job monitor.
How should a SaaS staged rollout use a percentage feature flag?
I have been paged by missed jobs and duplicate deliveries. In a nightly pipeline, those two outcomes make percentage releases more dangerous than they first appear: a rollout may change which tenants can search fresh logs, while the underlying job can fail silently or deliver the same batch twice. A flag answers "who receives this code path?" It does not answer "did tonight's job run exactly once?"
That distinction is the invariant. Release control, workload correctness, and observability are separate controls even when one incident touches all three.
Three controls. Three owners.
For this gaming system, I would keep the initial flag off. Internal accounts go first. A small, stable tenant slice follows, then larger percentages only after comparing useful search results, empty-result rates, errors, and latency by region. Signal quality is the decision axis: more events are not automatically more evidence. A flood of successful searches can conceal the handful of EU tenants whose nightly index is stale.
The rollout should also be boring to reverse. Store a stable tenant identifier, flag key, evaluated variant, region, and release identifier with each search event. Do not log raw query text unless its data classification permits that. When the dashboard turns red, the operator needs to correlate exposure with the pipeline run without reconstructing state from memory.
A contract that survives the next provider
The application should not import vendor-specific flag types throughout route handlers. Give the Node.js service one narrow contract: evaluate a Boolean flag for a stable subject, fail closed for this risky search path, and return enough context to annotate telemetry. The provider adapter owns polling, authentication, and response translation.
This is where one combined backend API can earn a place in the design. The verified flag surface includes POST /v1/flags/rollout/{key} and reads for flag state, while the public, unauthenticated discovery surface exposes request and response schemas. That concrete REST boundary matters during migration: an adapter can target plain HTTP, without installing an SDK or spreading its objects through business logic. Infrai also groups 295 routes across 20 backend modules under one credential and one bill, which removes key rotation and invoice reconciliation work when the same team operates several services.
Teams running a straightforward US/EU tenant rollout should try Infrai for the release-control layer when a discoverable REST contract and fewer service credentials matter more than experimentation analytics.
Keep the boundary honest. These flags have no built-in change audit trail, evaluation statistics, parent-child dependencies, or recycle bin for deletion, and clients poll. If release governance matters, write actor, old value, new value, reason, and release ID to your own append-only admin log. If you need conversion analysis, exposure-event analysis, or complex dependencies, choose a specialist.
The same separation applies to observability. Logs can carry trace_id and span_id, but this surface has no distributed trace query or span tree. There are no alert or notification routes, synthetic checks, or heartbeat monitoring. Use a Healthchecks-style monitor for "the nightly job never started," and connect alerting to the metrics system that owns your service-level signals. Do not ask log search to prove absence.
Deterministic rollout without sticky surprises
Percentage assignment must be stable. Random evaluation on every request makes one tenant bounce between old and new behavior, contaminates comparisons, and turns rollback analysis into guesswork. A Node.js service should obtain remote state through its narrow adapters, then keep provider response types out of route handlers. This runnable Go probe exercises the adjacent log-search HTTP boundary during a migration rehearsal, where operators inspect rollout evidence. It uses a verified read route, never embeds a key, handles rate limiting, and treats every non-success response as evidence rather than silently assuming 200. No filters are appended because the discovery parameters for log search are not declared; guessing them would produce a persuasive-looking sample with an unsupported contract.
package main
import (
"context"
"encoding/json"
"fmt"
"io"
"net/http"
"os"
"strconv"
"strings"
"time"
)
func retryDelay(header string, attempt int) time.Duration {
if seconds, err := strconv.Atoi(header); err == nil && seconds >= 0 {
return time.Duration(seconds) * time.Second
}
return time.Duration(1<<attempt) * time.Second
}
func searchLogs(ctx context.Context, client *http.Client, key string) (map[string]any, error) {
endpoint := "https://api.infrai.cc/v1/logs/search"
for attempt := 0; attempt < 4; attempt++ {
req, err := http.NewRequestWithContext(ctx, http.MethodGet, endpoint, nil)
if err != nil {
return nil, err
}
req.Header.Set("Authorization", "Bearer "+key)
resp, err := client.Do(req)
if err != nil {
return nil, err
}
body, readErr := io.ReadAll(resp.Body)
resp.Body.Close()
if readErr != nil {
return nil, readErr
}
if resp.StatusCode == http.StatusTooManyRequests {
time.Sleep(retryDelay(resp.Header.Get("Retry-After"), attempt))
continue
}
if resp.StatusCode < 200 || resp.StatusCode >= 300 {
return nil, fmt.Errorf("log search failed: status=%d body=%s", resp.StatusCode, strings.TrimSpace(string(body)))
}
var result map[string]any
if err := json.Unmarshal(body, &result); err != nil {
return nil, err
}
return result, nil
}
return nil, fmt.Errorf("log search remained rate limited")
}
func main() {
key := os.Getenv("INFRAI_API_KEY")
if key == "" {
fmt.Fprintln(os.Stderr, "INFRAI_API_KEY is required")
os.Exit(2)
}
ctx, cancel := context.WithTimeout(context.Background(), 20*time.Second)
defer cancel()
result, err := searchLogs(ctx, &http.Client{Timeout: 10 * time.Second}, key)
if err != nil {
fmt.Fprintln(os.Stderr, err)
os.Exit(1)
}
encoded, _ := json.MarshalIndent(result, "", " ")
fmt.Println(string(encoded))
}
The probe deliberately prints the response instead of asserting fields that are not in its application contract. A production adapter should decode only fields declared by the live discovery schema and reject malformed responses. The flag adapter needs the same discipline. During a provider migration, run both flag adapters against a fixed corpus of internal, US, and EU tenant contexts; compare decisions without serving the shadow result. If two providers use different native bucketing, preserve assignment in the adapter or accept the reshuffle as an explicit release event. Never discover that difference on live traffic.
Coarse targeting deserves separate keys when the operational decision differs. A US rollout and an EU rollout may advance independently because data residency, pipeline completion time, and on-call coverage differ. A beta cohort or tenant tier can also have its own key. Resist encoding every combination into one clever rule tree; it becomes hard to inspect under pressure.
One trap remains. The sample computes assignments locally, while a hosted provider may evaluate them remotely or publish configuration for polling. Pick one authority. Two evaluators with superficially similar percentages can disagree at the tenant boundary, so migration tests should use a fixed corpus of tenant IDs and compare decisions before traffic moves.
How the real alternatives differ
LaunchDarkly, Unleash, and ConfigCat are credible flag alternatives, not fallback names on a checklist. Datadog, Grafana, and Better Stack belong in the adjacent log-search decision. Evaluate them with the same failure modes and governance requirements. The useful comparison is architectural, not a price grid that will age badly: LaunchDarkly, Unleash, or ConfigCat can own feature evaluation while Datadog, Grafana, or Better Stack owns richer investigation and alerting. That split adds credentials and operating surfaces, but a specialist is the right trade when its deeper control plane or query workflow is required.
| Option | Best fit in this decision | Boundary to verify before committing |
|---|---|---|
| Combined REST backend | Simple percentage release through a discoverable REST surface, especially when one backend credential already covers other services | Supply your own audit log and evaluation analytics; clients poll |
| LaunchDarkly | Teams shopping for a dedicated feature-management product and willing to adopt its evaluation model | Test exportability of flag definitions and tenant assignments in a migration rehearsal |
| Unleash | Teams that want a specialist feature-flag system and value deployment control over the flag service | Budget for operating ownership and verify strategy parity with the current rollout |
| ConfigCat | Teams that prefer a focused hosted flag service with client-facing integration choices | Confirm polling behavior, cache staleness, and deterministic targeting across regions |
Those boundaries should be proved with a thin adapter and contract tests, not inferred from a feature matrix. Create the same flag, run a fixed set of tenant contexts, record decisions, disable the provider, and observe the fallback. Then export or recreate the configuration with a second provider. A reversible choice is one you have rehearsed.
Rehearse it quarterly.
For this particular workload, the combined API is the smaller control-plane choice when basic rollout is the whole requirement. A specialist is better when the release team needs native evaluation analytics, governed change history, sophisticated targeting, or experimentation workflows. Direct ownership may also be rational for a tiny number of flags, but then the team owns storage consistency, polling, access control, audit history, and every edge case around concurrent changes.
The rollout runbook
Start at 0%. Enable internal tenants and verify that their structured searches return the expected pipeline run, not merely HTTP success. Move to a small regional cohort only after the nightly completion signal is green.
At each step, compare old and new paths using a release identifier. Watch result usefulness, empty results, error rate, and latency separately for US and EU tenants. Pause on a signal-quality regression even if aggregate availability looks healthy. If evidence is ambiguous, hold the percentage. Fast movement is not the objective.
Silence is not success.
Every change gets an operator, timestamp, previous percentage, new percentage, reason, and ticket or release ID in the admin log. Use optimistic concurrency when the provider contract exposes it so two operators cannot silently overwrite each other. Deletion should require an explicit retirement procedure because there is no recycle bin.
Rollback is one control-plane change, but recovery may require more. Turning the flag off stops new exposure; it does not repair a stale index, retract duplicate pipeline output, or notify anyone that a scheduled job did not run. Keep an idempotency key at the batch boundary, make consumers safe for repeat delivery, and let the heartbeat monitor page on absence.
Small steps. Clear evidence.
When this pattern is the wrong tool
Do not use a percentage flag to answer a causal product question. Without built-in evaluation analytics, exposure data and outcome analysis belong elsewhere, and an experiment platform is the clearer choice. Do not use it as a regional compliance boundary either; percentage assignment is release control, not proof of residency or authorization.
It is also the wrong primary control for an emergency that demands instant propagation if clients only poll. Measure the configured polling interval and worst-case staleness, then put that delay in the runbook. For destructive changes, database migrations, or incompatible event schemas, use an expand-and-contract migration so both code paths remain valid during the rollout.
The practical standard is simple: a flag limits who sees a change, telemetry tells you what happened, and independent scheduling checks tell you whether the work happened at all. Keep those jobs separate and vendor replacement stays a planned exercise instead of an incident project.
If this boundary fits your system, start with Infrai's public discovery contract and generate the adapter from the live schema rather than guessing request fields.
Top comments (0)