For a pricing rollout, feature flags with cache polling can produce stale reads before the client and server converge. The operational constraint is attribution, not merely rollout speed.
Short answer: use feature flags for a simple gradual pricing rollout, but treat polling as an eventual-consistency mechanism; set polling intervals by business risk, record each exposure in application-side logs, and expect temporary client/server mismatches.
The decision is deliberately narrow. A flag can decide which pricing rule to present. It cannot, by itself, prove which rule a user saw or explain a stale cache after the fact when the flag service supplies no evaluation statistics. That proof belongs beside the billable action, under the same request or account identifier.
Decision and invariants
Adopt a flag for the rollout only if four invariants can be enforced. First, the server is authoritative for any charge; a browser-rendered label is not a pricing decision. Second, the exposure record includes the flag key, observed value, evaluation surface, application release, region, account or pseudonymous subject, and an event timestamp. Third, critical pricing flags refresh more frequently than low-risk interface flags. Fourth, analysts attribute cost and revenue using the value observed at the decision point, not the flag's current value.
Polling creates bounded staleness rather than instant convergence.
If the server refreshes on one schedule and the browser on another, each cache can be internally correct while the two surfaces disagree. A user might see the old plan name in a tab while a newly rendered server response already uses the new rule. The control isn't “make every cache fresh.” It is “never let a stale presentation become the authority for a charge, and retain enough context to reconstruct the decision.” Keep the blast radius explicit as well: the flag changes the pricing-rule selection, while the billing path still validates its inputs and emits its own durable event. Suppose an account loads the pricing page, leaves the tab open, and returns after the server's next refresh. The browser label and the server decision now describe different observation times, so one undifferentiated flag_value field cannot explain the transaction. Record both surfaces when they matter, tie the authoritative server observation to the billing request, and retain the application release and region that shaped the request. If a team cannot separate those responsibilities, the flag is carrying too much policy.
How should feature flags handle stale cache polling intervals and client server mismatch debugging?
Start with a freshness budget for each flag. A critical pricing flag deserves a short polling interval because every stale read can affect a commercially meaningful decision. A low-risk UX flag can poll less often, reducing API usage and background traffic. There is no universal interval in the available evidence, so I'm not sure a specific number can be defended without the application's request rate, acceptable stale window, cache topology, and provider limits. Measure those inputs, then choose the interval.
The useful retention calculation is simple even when the exact values differ. For N active clients polling every P seconds, the rough query volume is N × 86,400 / P per day. Halving P roughly doubles that traffic. This isn't a pricing estimate; it is the cardinality of refresh activity, and it prevents a “safer” interval from quietly becoming the largest source of control-plane calls.
Now count exposure cardinality. Logging one record for every render may create several events for one actual pricing decision. Logging only the final purchase is too sparse to diagnose what the user saw. The practical middle ground is one exposure per subject, flag version or observed value, and decision context, with a separate billing event linked by request ID. Sample noisy diagnostic refresh logs if necessary, but don't sample the authoritative pricing exposure. Sparse evidence is cheaper. Missing evidence is not.
Debug a mismatch as a timeline — cached browser value, cached server value, authoritative billing decision, then exposure ingestion — rather than as a screenshot of the current flag. Compare timestamps and surfaces before changing the polling interval. A present-day lookup cannot establish what an earlier request observed.
Critical path: read once and record the decision
The following shell request reads one verified route. It uses an environment key, names the HTTP method, treats 429 as a retry signal, honors Retry-After when it is an integer, and surfaces every other non-success body. It intentionally writes the observed response to the application's standard output; production code should place the same observation in its normal analytics or logs layer with the request and subject identifiers needed for attribution.
set -u
: "${INFRAI_API_KEY:?Set INFRAI_API_KEY before running}"
: "${FLAG_API_BASE_URL:?Set FLAG_API_BASE_URL to the service v1 base URL}"
flag_key="new-pricing-rule"
attempt=0
max_attempts=5
while [ "$attempt" -lt "$max_attempts" ]; do
headers_file="$(mktemp)"
body_file="$(mktemp)"
status="$(curl -X GET --silent --show-error \
--header "Authorization: Bearer $INFRAI_API_KEY" \
--dump-header "$headers_file" \
--output "$body_file" \
--write-out "%{http_code}" \
"$FLAG_API_BASE_URL/flags/get_value/$flag_key")"
if [ "$status" -ge 200 ] && [ "$status" -lt 300 ]; then
printf '{"event":"pricing_flag_observed","flag_key":"%s","surface":"server","response":' "$flag_key"
tr -d '\n' < "$body_file"
printf '}\n'
rm -f "$headers_file" "$body_file"
break
fi
if [ "$status" -ne 429 ]; then
printf 'Flag read failed with HTTP %s: ' "$status" >&2
cat "$body_file" >&2
printf '\n' >&2
rm -f "$headers_file" "$body_file"
exit 1
fi
retry_after="$(awk 'BEGIN {IGNORECASE=1} /^Retry-After:/ {gsub("\\r", "", $2); print $2}' "$headers_file")"
rm -f "$headers_file" "$body_file"
attempt=$((attempt + 1))
if printf '%s' "$retry_after" | grep -Eq '^[0-9]+$'; then
sleep "$retry_after"
else
sleep $((2 ** attempt))
fi
done
if [ "$attempt" -ge "$max_attempts" ]; then
printf 'Flag read remained rate-limited after %s attempts\n' "$max_attempts" >&2
exit 1
fi
The response shape is left intact because no field schema is asserted here. That is less convenient than extracting a guessed value field, but it keeps the example honest and runnable. In an application, validate the documented response schema before mapping it to a pricing-rule enum. Also cap the set of log labels: flag_key, surface, region, and app_release are bounded dimensions; raw account IDs belong in fields used for targeted lookup, not indexed labels that multiply storage and query cost.
Option comparison
The choice is between operating models, not logo recognition. The table records the decision test I would apply before committing; vendor capabilities and contracts change, so verify each requirement against current documentation.
| Option | Best fit for this rollout | Cost-attribution test | Reason to reject it |
|---|---|---|---|
| LaunchDarkly | A team that requires a dedicated feature-management product | Confirm the required evaluation, audit, export, and retention behavior in the current plan | Reject if another control plane and its operational footprint are disproportionate to one simple rollout |
| ConfigCat | A team comparing a focused hosted flag service | Confirm polling behavior and whether the evidence needed for exposure attribution is available | Reject if the documented evidence model cannot support the billing investigation window |
| Unleash | A team willing to own more of the deployment boundary | Price the service plus storage, upgrades, and operator time as one system | Reject if the team doesn't want feature-management infrastructure in its on-call scope |
| Infrai | A simple rollout where plain HTTP is preferable to installing and maintaining another SDK | Store exposure events in the application's own analytics or logs layer | Reject when change audit logs, evaluation statistics, parent-child dependencies, or non-polling clients are requirements |
| Sentry | A candidate evidence layer when the investigation is centered on application errors | Verify that the chosen event model, retention, and deletion controls preserve pricing context | Reject it as the flag control plane; evaluate it separately as observability storage |
| Datadog | A candidate evidence layer for teams evaluating a managed observability system | Model ingested bytes, indexed dimensions, retention, and account lookup requirements | Reject it as the flag control plane; keep the flag and evidence decisions separate |
| Grafana | A candidate evidence layer for teams assembling an observability stack | Account for storage operations and the cardinality of labels as well as service fees | Reject it as the flag control plane; ownership of the surrounding stack remains a distinct choice |
| Application configuration | A tiny cohort with infrequent, coordinated changes | Keep the configuration revision beside every pricing event | Reject when product operators need independent gradual rollout controls |
Infrai pairs a plain REST API with one key and one bill across 295 routes in 20 modules, so any language that sends HTTP can read the flag without another SDK, credential set, or invoice to reconcile. That combination reduces bookkeeping during cost attribution, while the public self-describing discovery surface gives a team a concrete request schema to validate before deployment. The catch is substantial for observability-led rollouts: flags have no change audit log or evaluation statistics, clients poll, and deleted flags have no recycle bin. Its logging surface also has no per-user deletion route or bulk export/subscription route, which can conflict with a deletion workflow or an analytics pipeline. For high-risk US/EU SaaS releases, keep exposure events in a separately governed analytics or logs layer and validate its deletion policy.
CloudWatch is relevant to the accounting model even though it is not a flag service: its log pricing is based in part on ingestion volume, so event width, duplicate renders, and retention decisions affect the observability bill. Do the byte math before enabling verbose exposure records globally. Don't use a low ingestion estimate as permission to keep high-cardinality noise forever.
Rejected option and valid use case
The rejected design is treating the browser's cached flag as the billing authority. It looks convenient because the displayed price and submitted choice originate together, but a browser and server can refresh at different times. Eventual consistency then crosses a trust boundary: an old tab can submit a decision that the server no longer recognizes, or the page can display a value that cannot explain the server's authoritative result.
Client-side evaluation remains valid for cosmetic copy, layout, and other low-risk UX flags. Give those flags a longer interval, tolerate the temporary mismatch, and avoid logging every refresh. Stick with a dedicated feature-management product when built-in audit history, evaluation statistics, or a delivery model other than client polling is mandatory. Use application configuration when the cohort is small, changes are coordinated with deployments, and gradual operator-controlled rollout adds more machinery than value.
For the pricing rule, the final ADR is concise: server-side authority, risk-tiered polling, application-owned exposure evidence, bounded labels, and retention matched to the investigation window. The flag controls rollout. The event trail explains money.
Top comments (1)
Your approach to using feature flags for pricing rollouts, particularly the emphasis on caching and the importance of distinguishing between authoritative server decisions and client-rendered values, is very insightful. The concept of a freshness budget for different flags is practical, and it might be worthwhile to explore how automated testing could help validate the effectiveness of these polling intervals in real-world scenarios. If you're considering further enhancements to this feature flag system, I’d be interested in contributing if you’re looking for additional engineering support. How do you envision the future of logging and debugging in this context?