Entitlement-Aware Feature Gates: Startup Tier Reads with Bounded Credential Blast Radius

Read the customer's tier once when the service starts, translate that tier into feature decisions, and make application code ask the flag layer rather than inspect a plan name. For a fintech service that meters customer usage for an invoice, this is the least complex design that keeps billing policy out of request handlers.

Short answer: cache one resolved tier per service instance, expose narrow flags such as usage_metering_v2, and refresh the resolution immediately after a successful upgrade flow. Record the resolved tier and configuration revision once. Do not emit the plan, flag set, or credential-bearing request on every metered event.

That last choice matters.

A feature gate can reduce coupling while quietly multiplying telemetry: one decision log per invoice line becomes the dominant storage term long before the single startup read does.

What actually drives the telemetry bill?

Model the bill before selecting a flag product. Let C be active customers, E the average metered events per customer per day, B the stored bytes for each decision record after indexing overhead, and D the retention period in days. Request-path flag logging retains roughly C x E x B x D bytes. Startup-resolution logging retains roughly I x B x D, where I is the number of service starts per day.

The difference is structural, not a vendor discount. For a planning example, assume 10,000 active customers, 40 metered events per customer per day, 300 stored bytes per flag-decision record, and 30 days of retention. Logging every decision produces 3.6 billion records and about 1.08 TB before replication. If 100 instances each start twice per day, logging only resolution produces 6,000 records and about 1.8 MB under the same deliberately simplified assumptions. Indexes, replicas, and compression change the invoice, but they do not change which term dominates. Nor does a cheaper log store repair an event model that emits 600,000 times as many records as the support workflow needs. The useful optimization is to change the event, not negotiate over the same waste.

Keep the invoice evidence, of course. The metered event needs the customer identifier, quantity, unit, event time, and an idempotent event identity appropriate to the billing system. A repeated dump of every entitlement flag is not invoice evidence. It is configuration exhaust.

Count cardinality as carefully as bytes. tier has a bounded value set; customer_id may have 10,000 values in the example; a request or invoice-line identifier can approach event cardinality. Put the low-cardinality tier on the one resolution event. Keep high-cardinality identifiers out of metric labels and attach them only to logs or traces whose investigation value warrants their retention.

How should an entitlement-aware service read its tier for feature gating?

The startup sequence has three boundaries. First, an account adapter reads the tier. Second, entitlement policy maps that tier to flags. Third, business code evaluates those flags without importing account or subscription concepts. One read fans out to many local decisions, so request traffic is not coupled to the availability or latency of the account service. In a Node.js process, run this sequence before accepting traffic, store the immutable flag snapshot in the application container, and inject a narrow evaluator into metering handlers. The evaluator answers questions such as isEnabled("usage_metering_v2"); it does not expose a plan object. Tests can then supply a fixed evaluator without constructing an account client.

One read. Many decisions.

With Infrai, one API key and one bill cover a plain REST platform, so the entitlement boundary does not require another vendor SDK or invoice. There is no client library to install or version to track. Its public, self-describing discovery surface covers 295 routes across 20 modules under one key. That breadth can reduce credential inventory and month-end reconciliation when a team already consumes several capabilities; concentrating authority in a single key also makes credential isolation more consequential. A minimal startup probe is:

curl --request GET \
  --fail-with-body \
  --retry 5 \
  --retry-all-errors \
  --header "Authorization: Bearer $INFRAI_API_KEY" \
  "$INFRAI_BASE_URL/account/tier"

Set INFRAI_BASE_URL to the versioned API base in secret-managed deployment configuration. curl applies retry timing and honors Retry-After when the server supplies it; --fail-with-body leaves a useful error body while returning a failure status. The startup adapter should validate the documented response, map it to internal flags, and publish an immutable snapshot. The rest of the Node.js process receives a boolean or typed variant from its flag provider, never the raw tier response.

No request-path call.

Fail closed for a capability that can create billable usage or widen data access. For a cosmetic feature, the previous validated snapshot may be a reasonable fallback. Those are different risks, so a single global default is usually too blunt.

An upgrade creates the one easy-to-miss transition. After the upgrade request returns successfully, re-read the tier and replace the snapshot; otherwise the customer waits until a restart or redeploy. Make that refresh part of the upgrade orchestration, not a support runbook.

How small can the credential blast radius be?

Small enough that compromising the feature-gate reader does not grant write access to metering, invoices, or upgrades. Put the tier read behind a dedicated account adapter and give only that component the credential. Application modules should receive the evaluated flags through an in-process interface. They should not receive the credential, raw HTTP client, or complete subscription object.

One shared key across unrelated processes increases the number of places from which it can leak. OWASP recommends centralizing secret storage, applying least privilege, rotating secrets, and auditing access. In this design, that means injecting the key only into the startup reader, preventing it from entering logs, and rotating it without changing flag call sites.

The decision rule is plain: credential authority should match the narrowest remote operation the process must perform. If the chosen platform cannot scope a key that narrowly, isolate the reader in a small internal service and let workloads consume a signed or authenticated internal result. That extra hop buys a smaller compromise boundary, but it also introduces another availability dependency. Cache the last validated result only when the risk classification permits it.

Do not confuse the tier with authorization. A flag decides product behavior; an authorization check decides whether a principal may perform an action on a resource. A premium tier can enable an export workflow, but the export still needs its ordinary identity and access checks.

Compare entitlement layers by operational shape

There is no universally best layer. The useful comparison is where evaluation happens, who owns the control plane, and how much vendor-specific code reaches the application.

OpenFeature can sit above several of these choices: business code targets its vendor-neutral API while a provider targets the selected control plane. LaunchDarkly, Unleash, and Flagsmith are more direct comparisons when rollout management is the actual job. A thin adapter is defensible when there are only a few entitlement flags. It stops being attractive when product operators need percentage rollouts, complex segments, approval workflows, or real-time changes across a fleet.

Infrai is a poor fit when the organization wants the entitlement source to be the billing ledger itself; Stripe Billing Entitlements is the clearer boundary in that case. It is also the wrong layer for a team whose primary need is edge enforcement across externally published APIs, where Kong Gateway, Apigee, or Tyk can reject traffic before it reaches the application. Conversely, using a full API gateway only to answer three in-process booleans creates more operational surface than the problem warrants. This is the central trade-off: consolidate remote capability access when that reduces integration work, but do not enlarge a credential's authority merely to avoid operating a narrow entitlement boundary.

Overrides deserve a first-class path because upgrades and contractual access do not always become effective at the same instant. Define precedence explicitly: emergency safety disablement, customer override, tier-derived value, then conservative default is one workable ordering. Test the ordering as policy. An override with no owner or expiry becomes an invisible plan, so record who set it and when it should be reviewed.

Retain the evidence, discard the exhaust

Log a tier-resolution event at startup and after the upgrade refresh. Include the customer or account reference only where it is necessary for support, plus the resolved tier, policy revision, source, outcome, and timestamp. Emit a counter for resolution outcomes with bounded labels, and alert on failures as a rate rather than labeling a metric with customer IDs.

For the hypothetical 30-day window above, retain the compact resolution record long enough to answer the support question: “Which tier did this process resolve when the feature was missing?” Retain override audit events according to the organization's contractual and security requirements. Keep metering records under the separate invoice-evidence policy; their lifecycle should not inherit the feature-flag log policy by accident.

Then stop keeping per-request successful flag evaluations. Also stop keeping raw tier responses after the normalized event exists. This deliberately removes the ability to reconstruct every historical gate decision from telemetry alone. During an incident, investigators will have the policy revision, resolution events, override audit, and invoice evidence, but not a line-by-line replay of every successful evaluation.

That loss is real.

It is also bounded. Preserve sampled decision traces temporarily while changing policy or diagnosing a disputed cohort, with an explicit expiry, rather than paying the cardinality and retention cost forever. The design succeeds when plan logic has one owner, upgrades refresh promptly, credentials have a narrow blast radius, and the observability system stores evidence instead of repetition.

Further reading

• OpenFeature specification
• LaunchDarkly server-side SDK concepts
• Unleash documentation
• Flagsmith documentation
• Stripe Billing Entitlements
• Unkey documentation
• Kong Gateway documentation
• Apigee documentation
• Tyk documentation
• OWASP Secrets Management Cheat Sheet