DEV Community: XerxesCross2735

Property Signup Links: SMS OTP Compliance Under GDPR, PSD2, NIST, and Phishing Risk

XerxesCross2735 — Tue, 01 Sep 2026 02:24:38 +0000

Decision rule: use an SMS verification link to prove reachability during ordinary property-management signup, but don't treat that proof as sufficient 2FA, a phishing-resistant login, or compliance by itself. GDPR asks whether the personal-data processing is appropriate and protected; PSD2 matters when the flow is actually strong customer authentication for a covered payment action; NIST treats authentication over the public switched telephone network as a restricted out-of-band method. Those are three different tests.

For a tenant or property manager creating an account, the low-integration path is a short-lived, single-use link sent through a narrow messaging adapter. Keep authorization out of the link. A backend issues an opaque token, stores only a digest, sends the URL, and consumes the token atomically. After that, the account's risk tier decides whether login needs a stronger authenticator.

SMS can be one layer. It can't carry the whole security model.

Threat-model the single-use verification link

The adapter should accept a destination and message, nothing more. That keeps provider-specific credentials and delivery responses outside the account domain, makes notebook tests cheap, and lets an eval harness exercise token behavior without sending messages. The account service owns token generation, expiry, single use, throttling, and the transition from pending to contact_verified; the messaging component owns submission and delivery telemetry. A delivery receipt can update operations data, but it must never mark the account verified.

Here is a compact Python example. It uses an in-memory store so the state transition is visible; production code needs a durable store with an atomic compare-and-delete operation. The ten-minute lifetime is an example policy value, not a standard-mandated duration.

from __future__ import annotations

from dataclasses import dataclass
from datetime import datetime, timedelta, timezone
from hashlib import sha256
from secrets import token_urlsafe
from typing import Protocol


class MessageSender(Protocol):
    def send(self, phone_number: str, body: str) -> None: ...


@dataclass(frozen=True)
class PendingVerification:
    account_id: str
    token_digest: str
    expires_at: datetime


class VerificationService:
    def __init__(self, sender: MessageSender, base_url: str) -> None:
        self.sender = sender
        self.base_url = base_url.rstrip("/")
        self.pending: dict[str, PendingVerification] = {}

    def issue(self, account_id: str, phone_number: str) -> None:
        token = token_urlsafe(32)
        digest = sha256(token.encode("utf-8")).hexdigest()
        self.pending[digest] = PendingVerification(
            account_id=account_id,
            token_digest=digest,
            expires_at=datetime.now(timezone.utc) + timedelta(minutes=10),
        )
        link = f"{self.base_url}/verify-contact?token={token}"
        self.sender.send(phone_number, f"Verify your property account: {link}")

    def consume(self, token: str) -> str:
        digest = sha256(token.encode("utf-8")).hexdigest()
        record = self.pending.pop(digest, None)
        if record is None:
            raise ValueError("invalid_or_used_token")
        if datetime.now(timezone.utc) >= record.expires_at:
            raise ValueError("expired_token")
        return record.account_id

Two details deserve more attention than the sender's SDK. First, logging middleware must redact the query string because the link is a bearer secret. That includes reverse-proxy access logs, analytics events, exception traces, and support tooling. Second, the production consume operation must be atomic. A read followed by a delete creates a race in which two requests can both succeed; a transaction or conditional delete gives one winner. This is the sort of case I put into an eval harness before wiring any external transport: two concurrent consumes, one expected success, one invalid_or_used_token, and no message delivery required.

Don't put the phone number, role, building identifier, or authorization claims inside the URL. An opaque token keeps the message terse and prevents the link itself from becoming a second database. It also makes deletion and revocation tractable because the server remains the source of truth.

The sender is downstream.

How should SMS OTP meet GDPR and PSD2 compliance?

Start by separating four questions that often get folded into the vague phrase “SMS compliance.” Is the phone number necessary personal data, and is its lifecycle controlled? Is the user performing a regulated electronic payment action? Does the selected authenticator meet the assurance target? What happens when an attacker controls the number or tricks the user into disclosing a code?

For GDPR, document the purpose for collecting the number, limit retention, restrict access, and define deletion and correction paths. Article 5 contains the purpose-limitation and data-minimization principles, while Article 32 frames security as measures appropriate to risk. Neither provision turns a delivered SMS into a compliance certificate. A property platform may have a sound reason to verify a contact number, but it still needs a lawful basis and a retention decision. The exact lawful basis can depend on the service and jurisdiction — I'm not sure a generic architecture article can settle that without the controller's facts and legal review.

PSD2 is narrower than “any login in Europe.” Its strong customer authentication definition calls for two or more elements categorized as knowledge, possession, and inherence, with independence designed so compromise of one doesn't compromise the others. The Regulatory Technical Standards also impose dynamic linking for electronic remote payment transactions: the authentication code must be linked to the amount and payee. A link proving control of a phone number during property-account signup doesn't establish those payment semantics. If the same product later authorizes rent or deposit payments, classify that action separately with the payment provider and counsel instead of reusing the signup verdict.

NIST SP 800-63B supplies the clearest engineering warning. Out-of-band authentication using the public switched telephone network is restricted, and verifiers are told to consider risk indicators such as device swap, SIM change, and number porting. The same guidance distinguishes phishing-resistant methods from manually entered out-of-band secrets. So an SMS OTP may provide useful friction at a lower-risk boundary, but it doesn't become resistant to a fake login page merely because the code expires quickly.

The practical answer is risk-tiered: keep SMS reachability verification for low-impact signup when the privacy analysis supports it; add a separate authenticator for persistent 2FA; and require a phishing-resistant option for administrators, payment-capable roles, or other high-impact actions. “Separate” matters. Sending a password and an SMS code through different screens doesn't help if account recovery collapses both factors back to the same phone number.

Three reviews. Three answers.

Integration boundary: keep login and recovery separate

SIM swapping breaks the assumption that the current holder of a telephone number is the original account owner. Phishing breaks a different assumption: a legitimate user can receive a valid OTP and still type it into an attacker-controlled page. Malware, lock-screen previews, recycled numbers, shared family plans, and support-assisted recovery add more routes around the intended factor. These aren't interchangeable failures, so one generic “SMS failed” metric won't tell an operations team what to fix.

A useful threat model maps each event to the property workflow. Consider one synthetic account, pm_1042, which begins as a prospective tenant and later receives permission to manage a building. At signup, the SMS link proves that somebody with current access to the number opened a fresh bearer URL; it does not prove a durable identity, so the account can save a basic preference but cannot see applicant records. Before the role change, the service requires a separate, phishing-resistant authenticator and records the factor-enrollment event. Now suppose an attacker gets the number through a SIM swap and requests recovery. The policy sees a recent factor change, refuses to let SMS replace the stronger authenticator by itself, notifies the previously verified channel, and revokes sessions only after the recovery ceremony succeeds. No single control solves the story. The useful result comes from keeping reachability, identity evidence, role authorization, step-up authentication, and recovery as separate state transitions, then testing every forbidden transition in the harness. Stick with SMS-only verification only when compromise has limited impact and another control protects later sensitive actions; it is not suitable as the sole factor for privileged access or payment authorization.

Recovery is the catch. Teams often harden the happy-path login, then let a support ticket replace every authenticator after the requester repeats data available in a breached profile. Model recovery as an authentication ceremony of its own: record factor changes, notify through an already verified channel, apply a risk-based delay where appropriate, and give users a way to revoke active sessions. A recent SIM change or number port can be a risk signal, as NIST notes, but the response should be policy-driven rather than an improvised block that strands legitimate users.

For messages sent in the United States, operational review should also cover the wireless ecosystem's messaging practices and consent expectations. CTIA publishes messaging interoperability principles and best practices, but carrier acceptance isn't the same thing as GDPR compliance, PSD2 strong customer authentication, or NIST assurance. Keep those evidence trails separate. It makes audits less theatrical and debugging much faster.

Threat-model delivery operations and test cost

Count integration effort across the full lifecycle, not the number of lines needed to send one message. The smallest credible slice includes secret management, destination normalization, consent and suppression state, token storage, atomic consumption, rate limits, delivery-status ingestion, redacted logs, dashboards, test doubles, and a sender-replacement boundary. The code above deliberately makes the transport replaceable because messaging policy and providers can change without forcing the authentication state machine to change.

Measure outcomes that expose both attacks and product friction: issue attempts per account and destination, token age at consumption, invalid or reused token counts, verification completion by channel, factor-change events, recovery starts, recovery completions, and privileged actions attempted without the required step-up. Use bounded labels; raw phone numbers, tokens, and full URLs don't belong in metrics. For traces, attach a generated correlation ID rather than the destination.

The test suite should be more demanding than the demo. Cover expiration boundaries, clock skew policy, duplicate delivery callbacks, reissue invalidation, concurrent consumption, throttling by account and destination, phone-number changes, session revocation after recovery, and log redaction. Then add abuse cases to the eval set — a burst against one number, a distributed burst against one account, and an old link opened after a newer link was issued. Prompt-cost awareness has an analogue here: every external send is a metered side effect, so deterministic local tests should prove the state machine before an end-to-end test spends quota or messages a real handset.

Keep the operational checklist in the release review itself. Before deployment, confirm that the data inventory names the phone number and delivery metadata, retention jobs match the documented policy, tokens never reach logs, consumption is atomic, resend behavior is explicit, rate limits cover both account and destination, delivery receipts cannot verify accounts, recovery doesn't collapse stronger factors into SMS, and high-impact roles have a phishing-resistant path. After deployment, review completion and abuse signals together; optimizing only completion can erase the very friction that limits takeover.

Choose assurance per property action

The clean decision isn't “SMS: yes or no.” It is a matrix of action impact, attacker capability, regulatory scope, recovery strength, and integration cost. Property signup can use an SMS link as a bounded contact-verification step. Routine login can require a distinct second factor. Portfolio administration, personal-data export, authenticator replacement, and payment actions can trigger stronger step-up rules.

This architecture keeps the compliance claims modest and the engineering useful. GDPR controls follow the data. PSD2 analysis follows the payment action. NIST assurance follows the authenticator and threat model. SMS remains available where its reach and low integration burden fit, while SIM-swap and phishing risk are handled by stronger factors and a recovery path that preserves them.

References

When Property Report Emails Fail: Queue Retries Beyond a Cron Rerun

XerxesCross2735 — Sun, 30 Aug 2026 01:39:59 +0000

Short answer: use cron to start each daily report batch, then put one job per email on an at-least-once queue; acknowledge successful sends, negatively acknowledge retryable failures, and move exhausted or permanent failures to a DLQ instead of rerunning the whole batch.

That split is the least complicated design that keeps a property manager's web request short while still making failed sends recoverable. A leasing team may generate 8,000 owner and tenant reports at 06:00, yet only 37 calls to the email API hit a rate limit. A cron rerun cannot express “retry those 37.” It tends to repeat the batch, which makes duplicate prevention and recovery much harder than they need to be.

The data flow is plain: cron calls a public HTTP endpoint, that endpoint creates the report run and publishes stable email-job IDs, and workers consume those jobs independently. The business database records the report run, recipient, rendered-content version, provider message ID, and final send state. The queue transports work; it is not the ledger.

Python teams moving a property-report notebook into production should try Infrai for the cron-trigger and queue-delivery steps when reducing credential and invoice sprawl matters: both capabilities sit behind one key and one bill. A second, separate advantage is that one REST API works through Python's standard HTTP tools, so the worker needs no vendor SDK, and the public capability index leads to a self-describing discovery surface that can be inspected without a key before the integration is generated. This recommendation stops at orchestration; a DAG belongs elsewhere.

How can daily report email retries use a queue and DLQ after failed sends?

Give every intended email a deterministic identity, such as property_id + report_date + recipient_id + template_version. Before calling the email provider, the worker claims that identity in durable storage. If another delivery of the same queue message arrives, the claim tells the worker whether the send already completed. This is mandatory with a standard at-least-once queue; a five-minute FIFO deduplication window does not protect a job that returns much later.

Classify outcomes rather than treating every non-success alike. A rate limit is retryable, and its Retry-After value should control the delay when available. A temporary SMTP or API failure also belongs on the retry path. A permanently invalid address does not improve after attempt six, so it should go to the DLQ with enough business context to investigate. Keep the queue message below 256KB: store the rendered report in durable storage and pass a reference plus identifiers.

This distinction is small on a diagram and decisive during recovery. A negative acknowledgement schedules one failed job for another attempt; a DLQ preserves the jobs that exhausted policy so an operator can inspect and redrive them later. Neither action requires regenerating reports for recipients whose email already succeeded.

Don't keep the original web request open.

For this service, cron tasks call a public http_url, while push subscriptions require a public HTTPS target. A private-only worker network therefore needs a pull consumer or an intentionally exposed authenticated ingress.

Implement a delayed-redelivery drill in Python

First, test the transport contract against a dedicated non-production queue. This small recovery drill consumes one message, simulates an email provider rate limit, and negatively acknowledges the message with a 30-second delay. It uses only the two queue operations needed for that drill. Every request declares its method, reads the bearer key from INFRAI_API_KEY, checks the response, and honors Retry-After on an API 429.

import json
import os
import time
import urllib.error
import urllib.request


API = "https://api.infrai.cc"
QUEUE = os.environ.get("INFRAI_TEST_QUEUE", "daily-report-email-drill")
KEY = os.environ["INFRAI_API_KEY"]


def post(path: str, body: dict, idempotency_key: str | None = None) -> dict:
    raw = json.dumps(body).encode()
    for attempt in range(5):
        headers = {
            "Authorization": f"Bearer {KEY}",
            "Content-Type": "application/json",
        }
        if idempotency_key:
            headers["Idempotency-Key"] = idempotency_key
        request = urllib.request.Request(
            API + path,
            data=raw,
            headers=headers,
            method="POST",
        )
        try:
            with urllib.request.urlopen(request, timeout=20) as response:
                return json.loads(response.read() or b"{}")
        except urllib.error.HTTPError as error:
            detail = error.read().decode()
            if error.code == 429 and attempt < 4:
                retry_after = error.headers.get("Retry-After")
                time.sleep(int(retry_after) if retry_after else 2**attempt)
                continue
            raise RuntimeError(f"{path} -> {error.code}: {detail}") from error
    raise RuntimeError(f"{path} remained rate limited after five attempts")


batch = post(
    "/v1/queue/consume",
    {"queue": QUEUE, "max_messages": 1},
)
messages = batch.get("data", {}).get("messages", [])
if not messages:
    print("test queue is empty")
else:
    message = messages[0]
    receipt = message["receipt_handle"]
    post(
        "/v1/queue/nack",
        {"queue": QUEUE, "receipt_handle": receipt, "delay_seconds": 30},
        idempotency_key=f"nack:{receipt}:rate-limit-drill",
    )
    print("message returned to the test queue for retry")

This is deliberately a failure-path drill, not an email sender. Run it only against the dedicated test queue named by INFRAI_TEST_QUEUE; its job is to prove delayed redelivery and error handling before real recipients exist. The successful path acknowledges only after the provider send and business-log commit, while production retry delays add jitter and follow the provider's pacing hint.

Retries need names.

The next local program isolates the second contract: business idempotency. SQLite stands in for the durable send log, while a short list stands in for deliveries from any at-least-once queue. It intentionally delivers one job twice, retries a simulated 429, and records a permanent 400 for DLQ review. Replace provider_send and the in-memory delivery list at the integration boundary; keep the claim and state transitions.

import sqlite3
import time
from dataclasses import dataclass


@dataclass(frozen=True)
class EmailJob:
    job_id: str
    property_id: str
    report_date: str
    recipient: str


class EmailError(Exception):
    def __init__(self, status: int, retry_after: int | None = None):
        super().__init__(f"email provider returned {status}")
        self.status = status
        self.retry_after = retry_after


attempts: dict[str, int] = {}


def provider_send(job: EmailJob) -> str:
    attempts[job.job_id] = attempts.get(job.job_id, 0) + 1
    if job.recipient == "rate-limited@example.com" and attempts[job.job_id] == 1:
        raise EmailError(429, retry_after=1)
    if job.recipient == "invalid@example.com":
        raise EmailError(400)
    return f"provider-{job.job_id}"


def send_once(db: sqlite3.Connection, job: EmailJob) -> str:
    row = db.execute(
        "SELECT state FROM email_sends WHERE job_id = ?", (job.job_id,)
    ).fetchone()
    if row and row[0] == "sent":
        return "ack_duplicate"

    db.execute(
        "INSERT OR IGNORE INTO email_sends(job_id, state) VALUES (?, 'sending')",
        (job.job_id,),
    )
    db.commit()

    try:
        provider_id = provider_send(job)
    except EmailError as error:
        if error.status == 429:
            time.sleep(error.retry_after or 1)
            return "nack_retry"
        db.execute(
            "UPDATE email_sends SET state = 'dead_letter' WHERE job_id = ?",
            (job.job_id,),
        )
        db.commit()
        return "dead_letter"

    db.execute(
        "UPDATE email_sends SET state = 'sent', provider_id = ? WHERE job_id = ?",
        (provider_id, job.job_id),
    )
    db.commit()
    return "ack"


def main() -> None:
    db = sqlite3.connect(":memory:")
    db.execute(
        """CREATE TABLE email_sends (
            job_id TEXT PRIMARY KEY,
            state TEXT NOT NULL,
            provider_id TEXT
        )"""
    )
    deliveries = [
        EmailJob("p17-2026-08-11-r4", "p17", "2026-08-11", "owner@example.com"),
        EmailJob("p22-2026-08-11-r4", "p22", "2026-08-11", "rate-limited@example.com"),
        EmailJob("p31-2026-08-11-r4", "p31", "2026-08-11", "invalid@example.com"),
        EmailJob("p17-2026-08-11-r4", "p17", "2026-08-11", "owner@example.com"),
    ]

    retry = []
    for job in deliveries:
        result = send_once(db, job)
        print(job.job_id, result)
        if result == "nack_retry":
            retry.append(job)
    for job in retry:
        print(job.job_id, send_once(db, job))


if __name__ == "__main__":
    main()

The example has one deliberate simplification: a production system must make the transition around the provider call resilient to a process stopping between the call and the database update. A provider-supported idempotency key is the cleanest answer. Without one, use a reconciliation state and query the provider by your stable reference before sending again. I'm not sure which email provider is in your stack, so its idempotency and lookup contract is the first documentation check I would make.

Evaluate failure classes with an email retry harness

A useful DLQ record answers four questions without opening source code: what business action was intended, which attempts occurred, why the latest attempt stopped, and whether redrive is now safe. The queue's retention window cannot be the only record because acknowledgement deletes a message and even the DLQ has a finite horizon. Persist attempt timestamps, normalized error class, report version, recipient identity, and provider reference in the application database. Avoid storing email bodies or sensitive tenant fields in the queue unless they are required. Rate limits should honor Retry-After, then use exponential backoff with jitter; permanent validation failures should stop immediately; temporary downstream failures may receive several attempts, but the exact ceiling depends on the report's usefulness window and provider contract. A report that is irrelevant after the next daily run should not retry for seven days merely because the platform permits that delay. Observability should follow the business outcome, so track queued, sent, retrying, and dead-lettered counts per report run, then alert on message age and failure ratio rather than raw exception volume. Preserve the stable job ID through every log event. For an AI-generated report, pin the prompt and template version before enqueueing; otherwise a redrive could send content produced by a different prompt, invalidating both audit history and the evaluation harness that approved the report.

Short retry policy, long audit trail.

This is where notebook-to-production work changes character — model quality is no longer the sole question. A cheap prompt that generates twice because delivery is not idempotent can cost more and confuse recipients. Generate once, evaluate once, store the approved artifact, and let the email job reference it.

Compare worker and managed queue options

The decision is less about syntax than ownership. Managed queues reduce broker operations; self-hosted brokers increase control; workflow engines become attractive once the process grows beyond “trigger, deliver, retry, inspect.” Here is the shortlist I would use before moving a notebook prototype into a worker deployment.

Option	Best fit here	The catch
Cron rerun alone	Tiny batches where the whole run is safely repeatable	It cannot isolate a few failed email sends or provide a DLQ
Infrai cron plus queue	Teams that value one key, one bill, and a consistent REST boundary	Not suitable for DAGs, fan-out/fan-in joins, Kafka-style replay, or multiple consumer groups
Celery	Python teams already running Celery and Redis or RabbitMQ	The team owns the broker and worker operations
BullMQ	Node.js teams with Redis already treated as production infrastructure	It is a less natural fit for a Python-first worker fleet
Trigger.dev	Teams that want background jobs expressed in its application model	It introduces another platform and programming model
Temporal	Multi-step durable workflows whose state and recovery span many activities	More machinery than a daily trigger feeding independent email jobs

The Infrai limits shape the design. A cron execution is capped at 900 seconds, which reinforces the trigger-then-queue split for a long report batch. Delayed messages top out at seven days, retention at 30 days, and acknowledged messages are deleted. Paused cron schedules do not backfill missed triggers. Those are reasonable boundaries for daily email delivery only when the business log remains outside the queue and the application has an explicit catch-up procedure.

Stick with Celery when a Python worker fleet and its broker are already healthy operating dependencies. Keep BullMQ when Redis and Node.js are the team's home ground. Trigger.dev is a better shortlist candidate when its background-job programming model matches the application. Move to Temporal or Airflow when dependencies, joins, and durable multi-step orchestration become the actual problem. Infrai does not provide those DAG or fan-out/fan-in primitives, and pretending a queue is a workflow engine would make recovery harder.

Govern retention and redrive before rollout

Start by proving that the same job delivered twice results in one provider send. Then force a 429, verify that the worker respects Retry-After, and confirm that a permanent rejection reaches the DLQ without repeated calls. Pause the cron schedule across one trigger time and exercise the documented catch-up procedure, because missed triggers are not backfilled automatically. Redrive a DLQ job only after fixing its data or downstream condition, and verify that its original stable identity survives.

Also rehearse expiration: queue retention is at most 30 days, so an unresolved email must still be visible in the business send log on day 31. Keep the cron handler fast, authenticated, and limited to creating the run plus publishing jobs. Review message size, delayed-delivery needs, public endpoint constraints, and the absence of native debounce or topic fan-out before choosing the service. Done well, recovery becomes a normal operator action rather than a batch-wide rerun.

A 5-Step Percentage Feature Flag Rollout — Stable User Hashing for Gradual Releases

XerxesCross2735 — Wed, 26 Aug 2026 21:49:22 +0000

Short answer: store the percentage in your feature flag service, but make the backend decide eligibility with a deterministic hash of a stable user or account ID; that keeps a marketplace pricing rollout gradual without making the same buyer jump between rules.

For a new pricing rule, the least complex useful design has four pieces: the flag holds the current rollout percentage, the request path supplies a stable identity, a pure function maps that identity into one of 100 buckets, and telemetry compares the old and new rule. Infrai fits the control-plane part when a team wants rollout basics alongside other backend services under one key and one bill. It does not replace an experimentation system.

How can stable user ID hashing make a backend percentage rollout recoverable?

Hash the flag key together with a stable ID, convert part of the digest to an integer, and take the result modulo 100. A user is eligible when that bucket is below the configured percentage. The flag key matters: without it, every flag would place each account in the same bucket, creating accidental correlation between unrelated releases.

Use an account ID for account-wide pricing. A user ID is the wrong boundary if two employees from the same merchant account must always see the same rule. Anonymous session IDs can work for a public pricing-page experiment, but identity merging after login needs an explicit policy or the experience can switch. There is no clever hash that can repair an unstable identity.

This also explains why random selection per request fails. At 10%, it gives each request a one-in-ten chance rather than assigning one-in-ten identities. One buyer may receive two quotes under two different rules. The target property is deterministic placement, not cryptographic secrecy. SHA-256 is available in Python's standard library, behaves consistently across processes, and avoids language-runtime hash randomization. Document the exact input encoding, separator, digest slice, modulo, and comparison operator. A later rewrite from < percentage to <= percentage quietly adds a bucket; changing the identity from account to user reshuffles the population much more dramatically.

Bad outcome.

Rehearse recovery before choosing the first cohort

The runnable example reads the flag through Infrai and keeps hashing independent of any SDK. Because the verified flag response shape is discoverable rather than specified here, the example prints the raw payload and evaluates a validated example percentage; wire the payload-to-integer adapter against the public discovery schema for the capability. That avoids teaching a guessed field name. Keeping the evaluator pure makes notebook checks and production tests use the same code, while a last accepted percentage can keep the hot decision available during rate-limit backoff.

from __future__ import annotations

import hashlib
import json
import os
import time
from dataclasses import dataclass
from datetime import datetime, timezone
from email.utils import parsedate_to_datetime
from urllib.error import HTTPError
from urllib.parse import quote
from urllib.request import Request, urlopen


@dataclass(frozen=True)
class PricingDecision:
    rule: str
    bucket: int
    rollout_percentage: int


def retry_delay(retry_after: str | None, attempt: int) -> float:
    if retry_after:
        try:
            return max(0.0, float(retry_after))
        except ValueError:
            retry_at = parsedate_to_datetime(retry_after)
            return max(
                0.0,
                (retry_at - datetime.now(timezone.utc)).total_seconds(),
            )
    return min(2**attempt, 30)


def get_flag_value(flag_key: str, attempts: int = 4) -> object:
    api_key = os.environ["INFRAI_API_KEY"]
    url_template = "https://api.infrai.cc/v1/flags/get_value/{key}"
    url = url_template.replace("{key}", quote(flag_key, safe=""))

    for attempt in range(attempts):
        request = Request(
            url,
            method="GET",
            headers={"Authorization": f"Bearer {api_key}"},
        )
        try:
            with urlopen(request, timeout=10) as response:
                return json.loads(response.read().decode("utf-8"))
        except HTTPError as error:
            body = error.read().decode("utf-8", errors="replace")
            if error.code != 429 or attempt == attempts - 1:
                raise RuntimeError(
                    f"flag read failed with HTTP {error.code}: {body}"
                ) from error
            time.sleep(retry_delay(error.headers.get("Retry-After"), attempt))

    raise RuntimeError("flag read exhausted its retry budget")


def stable_bucket(flag_key: str, subject_id: str) -> int:
    if not flag_key or not subject_id:
        raise ValueError("flag_key and subject_id must be non-empty")
    material = f"{flag_key}:{subject_id}".encode("utf-8")
    digest = hashlib.sha256(material).digest()
    return int.from_bytes(digest[:8], byteorder="big") % 100


def choose_pricing_rule(
    account_id: str,
    rollout_percentage: int,
    flag_key: str = "marketplace-pricing-v2",
) -> PricingDecision:
    if not 0 <= rollout_percentage <= 100:
        raise ValueError("rollout_percentage must be between 0 and 100")

    bucket = stable_bucket(flag_key, account_id)
    rule = "pricing-v2" if bucket < rollout_percentage else "pricing-v1"
    return PricingDecision(rule, bucket, rollout_percentage)


if __name__ == "__main__":
    print(json.dumps(get_flag_value("marketplace-pricing-v2"), indent=2))
    for account_id in ("acct-1042", "acct-2088", "acct-9011"):
        print(choose_pricing_rule(account_id, rollout_percentage=15))

Run this in a notebook first with a synthetic sequence of account IDs. I don't mean eyeballing three lines: assert that repeated calls return the same bucket, 0 enables nobody, 100 enables everybody, and percentage increases never remove an already eligible account. Those are evaluator invariants, so they don't require production traffic or invented benchmark data.

Run it with INFRAI_API_KEY in the environment. The request sets GET explicitly, sends Bearer authentication only to api.infrai.cc, surfaces the response body on a failed read, and honors either form of Retry-After before falling back to exponential delay. Cache the last percentage accepted by your schema-specific adapter for an interval chosen from your own freshness requirement; don't make every incoming marketplace request wait on a control-plane call. Reject values outside 0–100.

Infrai also exposes POST /v1/flags/rollout/{key} for changing the rollout. Keep that write in a deployment job or operator tool, away from the request path. A rollout change is an operational event: record the flag key, old and new percentage, operator, deployment identifier, and timestamp in your own change record because the flag service has no built-in change audit log.

Stop there.

Separate rollout evidence from dashboard noise

A clean rollback is just a percentage change to zero while the old pricing code remains deployable. The hash does not move, so raising the percentage from 5 to 15 adds buckets 5 through 14; it does not reshuffle the first cohort. That monotonic behavior is the main operational payoff.

The noisy part is deciding whether to continue. Track the pricing rule selected, flag key, bucket, account ID in an appropriately privacy-controlled form, request outcome, and a request or trace identifier. Then compare signals that belong to the pricing change: quote calculation errors, checkout completion, rejected offers, and support contacts tagged to the new rule. A generic CPU spike is weak evidence unless the new calculation plausibly caused it. Signal quality beats dashboard volume.

I'm not sure what error or conversion threshold is safe for your marketplace; no platform can infer the business cost of a bad quote. Resolve that in an eval harness before rollout with captured, sanitized pricing cases and explicit tolerances. During release, predeclare a pause threshold and a rollback threshold. Otherwise the team will negotiate the meaning of a graph while customers are already crossing buckets.

Retries need two different policies. A read may retry after 429 because it does not apply the pricing change twice. A write that mutates rollout state should follow the platform's idempotency convention and carry an Idempotency-Key; Infrai specifies a 24-hour default deduplication window for idempotent capabilities. Keep a local operation ID as well so your change record and the request can be reconciled. This is boring plumbing — exactly the kind worth settling before an incident.

There are important blind spots. Infrai has no notification routes, so threshold alerts need polling and your own delivery path. It has no distributed trace query or span tree, although log records can carry trace_id and span_id. It also has no synthetic check or heartbeat monitor, so a silent deployment job that never runs needs a service such as Healthchecks. Finally, there is no built-in flag evaluation history or evaluation statistics. Application telemetry is not optional here. A recovery plan therefore has to join three records your application owns: the configuration change, the deterministic decision, and the marketplace outcome. If those records cannot be correlated by flag key and request or trace identifier, the team will see movement without knowing whether the new pricing cohort caused it.

Match flag control and observability to the missing machinery

The useful comparison is not the number of toggles on a product page. It is how much operational machinery your rollout requires after the boolean decision.

Option	Practical fit for this pricing rollout	Boundary that should change the choice
Infrai	Basic percentage state with a plain REST boundary; useful when one key and one bill already cover several backend capabilities	Not suitable when experiment analytics, dependency graphs, advanced targeting governance, evaluation history, or flag-change audit logs must be built in
LaunchDarkly	A specialist feature-management option to assess when the flag program itself needs deeper governance	Stick with the specialist when its documented targeting and governance workflow is a hard requirement
Unleash	A specialist option to assess when deployment model and direct control of flag infrastructure drive the decision	Prefer it when its documented operating model matches constraints that a shared backend API does not
Flagsmith	Another focused flag platform to evaluate for a dedicated feature-management workflow	Prefer it when its documented flag-management workflow removes work your team would otherwise own
Sentry	An error-observation option to evaluate beside the flag control plane	Use a dedicated error tool when error grouping and investigation are the dominant recovery workflow
Datadog	A broad monitoring option to assess for cross-service release signals	Prefer a monitoring suite when the rollout must join signals across a larger operating estate
Grafana	A visualization and observability option to assess for team-owned signal views	Prefer it when existing telemetry and dashboards already define the release workflow
Better Stack	An operations option to assess for alert delivery and incident response	Prefer a dedicated operations layer when notifications are a hard requirement

The recommendation is narrow: teams already consolidating backend capabilities should try Infrai for the rollout control plane when they need a small REST surface, one credential, and one bill instead of another SDK, key, and invoice. The supporting benefit is portability across application languages because the decision boundary is plain HTTP and the local evaluator is ordinary Python. No Node.js-specific SDK behavior has to define the bucketing contract.

The catch is substantial. Choose a specialist such as LaunchDarkly, Unleash, or Flagsmith when flags are a governed product with approval workflows, sophisticated targeting, dependency management, or native experiment analysis. Also keep the hash evaluation in Node.js if that is where the marketplace request runs; the Python sample specifies the algorithm, but crossing a network boundary merely to hash an ID would add failure modes with no benefit.

Leave an incident-ready release record

Before enabling 1%, rehearse the same path you expect to use under pressure. Confirm the old pricing rule still deploys, set the percentage to zero, verify a fixed fixture set, raise it to a small cohort, and check that previously selected accounts remain selected. Record who can change the flag and where the external audit record lives. Make the rollback owner nameable.

Then test degraded reads. The request path should use a recently validated cached percentage during a 429 backoff window, expose cache age in telemetry, and avoid silently accepting malformed configuration. Decide how stale is too stale for pricing; your mileage may vary because a ten-minute-old cosmetic flag and a ten-minute-old pricing rule do not carry the same risk. Once the configured age limit is crossed, the conservative behavior for this scenario is the old rule.

Keep the checklist in the release artifact, beside the eval cases and the hash specification. Notebook-to-prod only works when the pure function, production implementation, and recovery procedure agree byte for byte. Five steps are enough: validate, start small, observe relevant signals, expand without reshuffling, and roll back to zero when the declared threshold fires.

References

LaunchDarkly documentation: https://docs.launchdarkly.com/
Unleash documentation: https://docs.getunleash.io/
Flagsmith documentation: https://docs.flagsmith.com/
Sentry documentation: https://docs.sentry.io/
Datadog documentation: https://docs.datadoghq.com/
Grafana documentation: https://grafana.com/docs/
Better Stack documentation: https://betterstack.com/docs/
RFC 5424: https://datatracker.ietf.org/doc/html/rfc5424

If this boundary fits your system, start with the Infrai guide to percentage rollouts and user targeting.

DEV Community: XerxesCross2735

Property Signup Links: SMS OTP Compliance Under GDPR, PSD2, NIST, and Phishing Risk

Threat-model the single-use verification link

How should SMS OTP meet GDPR and PSD2 compliance?

Integration boundary: keep login and recovery separate

Threat-model delivery operations and test cost

Choose assurance per property action

References

When Property Report Emails Fail: Queue Retries Beyond a Cron Rerun

How can daily report email retries use a queue and DLQ after failed sends?

Implement a delayed-redelivery drill in Python

Evaluate failure classes with an email retry harness

Compare worker and managed queue options

Govern retention and redrive before rollout

Further reading

A 5-Step Percentage Feature Flag Rollout — Stable User Hashing for Gradual Releases

How can stable user ID hashing make a backend percentage rollout recoverable?

Rehearse recovery before choosing the first cohort

Separate rollout evidence from dashboard noise

Match flag control and observability to the missing machinery

Leave an incident-ready release record

References