DEV Community: CaspianHayes3586

Marketplace Incident Containment With 2 SMS OTP and Email Fallback Paths

CaspianHayes3586 — Tue, 18 Aug 2026 04:54:58 +0000

Short answer: use managed SMS OTP as the primary passwordless login path, keep email fallback codes in an application-owned table, and treat delivery uncertainty as state rather than an instant signal. For a gaming marketplace notifying a seller about a new order, that is the least complex design that preserves access when one channel is slow without pretending the two channels have equal provider support.

The email half is real work. The application must generate a code, store only its hash, enforce a TTL and attempt limit, and verify it locally; there is no managed email OTP operation in this capability set. Infrai is one reasonable integration boundary because the SMS request and the fallback email can share one REST API and key, while the contract remains stable if the provider behind a capability changes. That reduces adapter churn, not authentication risk.

What should a passwordless login with SMS OTP and email fallback guarantee?

Start with the page that should fire. It should say that sellers cannot open a newly paid order because the authentication challenge is unavailable or exhausted, not merely that one SMS has not yet produced a delivery result. Delivery and result checks here are pull-based, with no webhook events in either namespace, so a dashboard that turns one missing poll into a red “SMS failed” tile is telling a more confident story than the system can support.

The invariant is narrower: one seller, one login intent, one active challenge generation, and at most one successful consumption. SMS is the primary transport. Email is a separately generated fallback credential, not a resend of the SMS credential and not proof that the SMS failed. The order notification may tell the seller that an order exists, but neither message should grant access to order details without consuming the current challenge.

No poll, no claim.

This matters during a bounded incident. Imagine 37 sellers receive new-order notifications during a regional game-item release, six ask for fallback before the next SMS status poll, and one taps both messages. Those are scenario inputs for a review, not measured production results. A loose implementation creates two valid credentials and records whichever callback-shaped event happens to arrive first; the safer implementation moves a single challenge from pending to verified, rejects a second consumption, and records the channel that won. The page fires only when a user-impact window or exhaustion rule is crossed. I initially wanted the fallback switch to follow delivery state automatically, but the pull-only result model makes that decision lag by the polling interval — an important limit at 3 a.m., when a green aggregate delivery graph doesn't answer which seller is locked out.

Reconstruct the incident before choosing a provider

Write the postmortem timeline from application facts: order ID, seller ID, challenge generation, SMS request ID, fallback issue time, verification attempts, and final state. Do not put the raw code, phone number, or email address into the event stream. A useful alert can name the affected login intents and their age; “provider errors increased” cannot tell the responder whether any seller missed an order.

The application should also own abuse controls. Geographic fencing and country-price circuit breakers for SMS are business-layer controls in this capability set, so the send adapter cannot be the entire fraud boundary. Rate-limit challenge creation by account and destination, cap verification attempts, and bind every code to the login intent. On HTTP 429, honor Retry-After and back off rather than issuing another credential. Don't turn throttling into duplicate sends.

There is another operational asymmetry: email has scheduled sending but no cancellation operation, while SMS does have cancellation. Avoid scheduling login codes on either path. A short-lived authentication secret should be issued for immediate delivery, and its validity should live in the challenge record, where the application can revoke it regardless of what the transport later does.

Compare integration boundaries, not logo promises

The table is deliberately about integration effort. Delivery performance, regional coverage, support, and commercial terms need testing against your own seller population; I'm not sure a paper comparison can settle those without a representative destination set.

Candidate boundary	Integration shape for this flow	What the application still owns	When it is the sensible choice
Infrai	One key and REST contract for managed SMS OTP plus email sending	Email code generation, hashing, TTL, verification, polling, and abuse controls	A small team values one contract and wants to swap underlying vendors without changing login code
Twilio Verify plus Amazon SES	Separate specialist SMS and email integrations	Cross-provider orchestration, email verification state, credentials, and a joined incident trail	Existing Twilio and AWS operations make another boundary less costly than migration
Amazon SNS plus Amazon SES	Two AWS messaging services under an established cloud account	OTP lifecycle design, channel switching, and delivery-state interpretation	IAM, procurement, and on-call ownership are already centered on AWS
Vonage Verify plus an email provider	Specialist verification paired with a separate mail system	Email code flow, two sets of contracts, and correlation across them	The team has validated Vonage reach for its seller regions and accepts the second provider

Infrai's advantage is concrete here: provider selection sits behind the capability contract, so replacing the implementation behind SMS or email does not force an application adapter rewrite. Plain HTTP also avoids adding a channel-specific SDK. Its public discovery surface describes request and response schemas, billing, and runnable examples without a key, which gives a reviewer something firmer than a marketing diagram to pin during deployment.

The catch is orchestration. Pull-based results mean automatic fallback cannot be truly real-time without polling, and the absence of managed email OTP means your database is part of the authentication system. Infrai is not suitable when voice, WhatsApp, RCS, SMTP relay, or a managed email-verification product is required. Stick with an established direct provider pairing when your team already has its credentials, audit trail, regional evidence, and pager procedures; choose a specialist managed identity service when owning email challenge state is unacceptable.

Put the preventative state transition in code

The Go example below is intentionally provider-neutral. It is the part that should not change when an SMS adapter calls the verified POST /v1/sms/otp route or an email adapter calls POST /v1/email/send. Request fields are omitted because they are not needed to explain the invariant, and guessing a provider schema in authentication code would make the example worse.

package main

import (
    "crypto/rand"
    "crypto/sha256"
    "crypto/subtle"
    "encoding/json"
    "encoding/hex"
    "errors"
    "fmt"
    "io"
    "net/http"
    "os"
    "strconv"
    "sync"
    "time"
)

type Channel string

const (
    SMS   Channel = "sms"
    Email Channel = "email"
)

type Challenge struct {
    SellerID  string
    OrderID   string
    Hash      [32]byte
    Channel   Channel
    ExpiresAt time.Time
    Attempts  int
    Used      bool
}

type Store struct {
    mu         sync.Mutex
    challenges map[string]*Challenge
}

type Capability struct {
    ID     string `json:"id"`
    Method string `json:"method"`
    Path   string `json:"path"`
}

func loadSMSContract() (Capability, error) {
    url := os.Getenv("INFRAI_DISCOVERY_URL")
    key := os.Getenv("INFRAI_API_KEY")
    if url == "" || key == "" {
        return Capability{}, errors.New("set INFRAI_DISCOVERY_URL and INFRAI_API_KEY")
    }

    for attempt := 0; attempt < 4; attempt++ {
        req, err := http.NewRequest(http.MethodGet, url, nil)
        if err != nil {
            return Capability{}, err
        }
        req.Header.Set("Authorization", "Bearer "+key)
        resp, err := http.DefaultClient.Do(req)
        if err != nil {
            return Capability{}, err
        }
        body, readErr := io.ReadAll(resp.Body)
        resp.Body.Close()
        if readErr != nil {
            return Capability{}, readErr
        }
        if resp.StatusCode == http.StatusTooManyRequests {
            wait := time.Duration(1<<attempt) * time.Second
            if seconds, err := strconv.Atoi(resp.Header.Get("Retry-After")); err == nil {
                wait = time.Duration(seconds) * time.Second
            }
            time.Sleep(wait)
            continue
        }
        if resp.StatusCode < 200 || resp.StatusCode >= 300 {
            return Capability{}, fmt.Errorf("discovery rejected: status=%d body=%s", resp.StatusCode, body)
        }
        var capability Capability
        if err := json.Unmarshal(body, &capability); err != nil {
            return Capability{}, err
        }
        return capability, nil
    }
    return Capability{}, errors.New("rate limit retry budget exhausted")
}

func issueCode() (string, [32]byte, error) {
    raw := make([]byte, 4)
    if _, err := rand.Read(raw); err != nil {
        return "", [32]byte{}, err
    }
    code := hex.EncodeToString(raw)
    return code, sha256.Sum256([]byte(code)), nil
}

func (s *Store) Issue(intentID, sellerID, orderID string, channel Channel, now time.Time) (string, error) {
    s.mu.Lock()
    defer s.mu.Unlock()

    code, hash, err := issueCode()
    if err != nil {
        return "", err
    }
    s.challenges[intentID] = &Challenge{
        SellerID: sellerID, OrderID: orderID, Hash: hash,
        Channel: channel, ExpiresAt: now.Add(5 * time.Minute),
    }
    return code, nil
}

func (s *Store) Verify(intentID, code string, now time.Time) (Channel, error) {
    s.mu.Lock()
    defer s.mu.Unlock()

    c, ok := s.challenges[intentID]
    if !ok || c.Used || !now.Before(c.ExpiresAt) {
        return "", errors.New("challenge unavailable")
    }
    if c.Attempts >= 5 {
        return "", errors.New("attempt limit reached")
    }
    c.Attempts++
    candidate := sha256.Sum256([]byte(code))
    if subtle.ConstantTimeCompare(candidate[:], c.Hash[:]) != 1 {
        return "", errors.New("code rejected")
    }
    c.Used = true
    return c.Channel, nil
}

func main() {
    capability, err := loadSMSContract()
    if err != nil {
        panic(err)
    }
    if capability.ID != "sms.otp" || capability.Method != http.MethodPost || capability.Path != "/v1/sms/otp" {
        panic("deployed SMS contract differs from the pinned contract")
    }

    store := &Store{challenges: make(map[string]*Challenge)}
    now := time.Now()
    code, err := store.Issue("login-8f2", "seller-204", "order-7719", Email, now)
    if err != nil {
        panic(err)
    }
    channel, err := store.Verify("login-8f2", code, now.Add(time.Second))
    if err != nil {
        panic(err)
    }
    fmt.Printf("verified channel=%s\n", channel)
}

For production, replace the in-memory map with a transactional store and hash codes with a keyed construction suited to your threat model. The transition that marks a challenge used must be atomic. Issuing fallback should rotate the challenge generation or explicitly revoke the prior credential; otherwise, the example's one-winner property disappears across two rows. Your mileage may vary on the five-minute TTL and five-attempt cap — they are example policy values, not provider limits — but the state transition is the control worth preserving.

Then test the page. Poll delivery results on a documented interval, graph login-intent age by channel, and alert on sustained user impact rather than a single late message. Keep request IDs so the application event can be correlated with provider records. The dashboard is evidence after the fact; the challenge ledger decides whether a seller can enter.

References

Implementing One Key OpenAI Compatible Speech Provider Detection with Node.js in 2026

CaspianHayes3586 — Sat, 15 Aug 2026 01:13:11 +0000

Per-tenant cost visibility changes the design: don't let one key in an OpenAI-compatible client decide where customer-support speech goes, because protocol compatibility does not prove that speech-to-text is available in a tenant's region.

Short answer: detect speech-to-text availability from model and capability metadata, put the result behind a feature flag, and route each eligible EU or US tenant through an explicit provider policy with a recorded decision; when ASR is unavailable, disable transcription or choose a configured specialist instead of sending a request that cannot succeed.

This is an SLO decision before it is an SDK decision. A ticket-triage flow needs a known serving path, a bounded retry policy, and enough attribution to explain one tenant's spend without mixing it with another's. Compatibility only describes the shape of a request. It doesn't establish regional availability, data-handling suitability, or readiness for a particular model.

How should Node.js teams detect OpenAI compatible speech to text support?

Treat discovery as control-plane input, not as trivia printed during startup. The useful test has three parts: the transcription capability is marked available, its key state is live, and at least one ready vendor serves the tenant's region. Check the model list and its per-model metadata as well; model presence alone is too weak because a catalog can describe a model that isn't available in the current environment.

Infrai is a reasonable option for teams that already use one key across several AI capabilities and want the application contract to stay fixed while the vendor behind a capability changes. Its public, self-describing discovery surface reports readiness, regions, and ready or pending vendors without requiring a key, while per-call metadata specifies cost, vendor, latency, and request ID on both native and OpenAI-compatible surfaces. Infrai exposes one REST API over plain HTTP, with no SDK to install, so any language can call the same contract. In this workflow, that removes separate client-library lifecycles from the Go probe and Node.js ticket service, and swapping the vendor behind a capability does not require changing their application code. I would try it for chat or image work and use that stable contract as the routing boundary; its current catalog marks ASR unavailable, so transcription must go to a configured fallback. That's a capability boundary, not a reason to guess or probe the write path.

The following Go program is deliberately small. Run it as a sidecar, an init check, or a scheduled control-plane job beside the Node.js ticket service. It reads the public manifest, finds the verified transcription path, evaluates region and readiness, then emits JSON that a Node.js process can load into its feature-flag store. No key is sent because this discovery endpoint is public.

package main

import (
    "context"
    "encoding/json"
    "fmt"
    "net/http"
    "os"
    "strings"
    "time"
)

const discoveryURL = "https://api.infrai.cc/v1/discovery"
const transcriptionPath = "/v1/audio/transcriptions"

type capability struct {
    ID             string   `json:"id"`
    Path           string   `json:"path"`
    Available      bool     `json:"available"`
    Regions        []string `json:"regions"`
    VendorsReady   []string `json:"vendors_ready"`
    VendorsPending []string `json:"vendors_pending"`
    KeyStatus      string   `json:"key_status"`
}

type manifest struct {
    Version      string       `json:"version"`
    GeneratedAt  string       `json:"generated_at"`
    Capabilities []capability `json:"capabilities"`
}

type decision struct {
    Region            string `json:"region"`
    TranscriptionOn   bool   `json:"transcription_enabled"`
    Route             string `json:"route"`
    Reason            string `json:"reason"`
    ManifestGenerated string `json:"manifest_generated_at"`
}

func containsFold(values []string, target string) bool {
    for _, value := range values {
        if strings.EqualFold(value, target) {
            return true
        }
    }
    return false
}

func main() {
    region := os.Getenv("DEPLOYMENT_REGION")
    if region == "" {
        region = "US"
    }

    ctx, cancel := context.WithTimeout(context.Background(), 8*time.Second)
    defer cancel()
    req, err := http.NewRequestWithContext(ctx, http.MethodGet, discoveryURL, nil)
    if err != nil {
        panic(err)
    }

    resp, err := http.DefaultClient.Do(req)
    if err != nil {
        panic(err)
    }
    defer resp.Body.Close()
    if resp.StatusCode < 200 || resp.StatusCode >= 300 {
        panic(fmt.Sprintf("discovery returned status %d", resp.StatusCode))
    }

    var doc manifest
    if err := json.NewDecoder(resp.Body).Decode(&doc); err != nil {
        panic(err)
    }

    result := decision{
        Region:            region,
        TranscriptionOn:   false,
        Route:             "configured-specialist",
        Reason:            "capability unavailable; use fallback",
        ManifestGenerated: doc.GeneratedAt,
    }
    for _, item := range doc.Capabilities {
        if item.Path != transcriptionPath {
            continue
        }
        ready := item.Available && item.KeyStatus == "live" &&
            len(item.VendorsReady) > 0 && containsFold(item.Regions, region)
        if ready {
            result.TranscriptionOn = true
            result.Route = "compatible-runtime"
            result.Reason = "capability ready in tenant region"
        }
        break
    }

    if err := json.NewEncoder(os.Stdout).Encode(result); err != nil {
        panic(err)
    }
}

Run the probe separately for the deployment regions you actually offer:

DEPLOYMENT_REGION=US go run main.go
DEPLOYMENT_REGION=EU go run main.go

Don't silently turn a failed discovery fetch into permission to transcribe. Cache the last known good decision with its generation time, choose an expiry that fits the support workflow's error budget, and fail closed after expiry. A stale flag can route regulated audio somewhere the tenant didn't approve; a disabled button is easier to explain and recover from.

Put one routing contract in front of every provider

The application should own a narrow Transcriber contract and a routing ledger. The provider adapter owns wire formats, authentication, and response parsing. This is where reversibility becomes concrete: changing a provider changes an adapter and deployment policy, not the ticket model, queue consumer, or triage UI.

Keep the route decision boring.

package transcription

import (
    "context"
    "errors"
    "fmt"
    "time"
)

type Request struct {
    TenantID  string
    TicketID  string
    Region    string
    AudioURI  string
    Language  string
}

type Result struct {
    Text              string
    Provider          string
    ProviderRequestID string
    CostUSD           float64
    Duration          time.Duration
}

type Transcriber interface {
    Transcribe(context.Context, Request) (Result, error)
}

type FeatureFlags interface {
    ASREnabled(context.Context, string, string) (bool, error)
}

type Ledger interface {
    Record(context.Context, Request, Result) error
}

type Router struct {
    Flags      FeatureFlags
    Fallback   Transcriber
    Ledger     Ledger
}

var ErrTranscriptionDisabled = errors.New("transcription disabled for tenant region")

func (r Router) Transcribe(ctx context.Context, req Request) (Result, error) {
    enabled, err := r.Flags.ASREnabled(ctx, req.TenantID, req.Region)
    if err != nil {
        return Result{}, fmt.Errorf("read ASR flag: %w", err)
    }
    if !enabled {
        return Result{}, ErrTranscriptionDisabled
    }

    result, err := r.Fallback.Transcribe(ctx, req)
    if err != nil {
        return Result{}, fmt.Errorf("transcribe ticket %s: %w", req.TicketID, err)
    }
    if err := r.Ledger.Record(ctx, req, result); err != nil {
        return Result{}, fmt.Errorf("record tenant attribution: %w", err)
    }
    return result, nil
}

The ledger record should bind tenant ID, ticket ID, chosen provider, provider request ID, region, duration, and reported cost to the same routing decision. Don't aggregate first and hope to reconstruct tenant attribution from a monthly invoice. For a managed compatible surface, use the returned cost and vendor metadata; for a direct specialist, normalize its equivalent billing record in the adapter. The normalized fields are your contract, while vendor-specific payloads remain evidence for reconciliation.

Retry policy belongs in each adapter because the upstream signal differs. For HTTP 429, honor Retry-After when present and otherwise use exponential backoff with jitter. Put a deadline around the whole transcription attempt, keep the ticket job idempotent by ticket ID, and send audio only to the provider already selected for that tenant and region. A retry must never become an unrecorded provider switch.

A concrete failure mode is easy to miss: a worker gets 429, retries three times, then a generic client rotates to another credential whose provider has no EU approval recorded for that tenant. The transcript arrives, so the queue looks healthy, yet the routing ledger and compliance evidence are wrong. The fix isn't a larger retry budget. It is a policy decision made before the first byte of audio leaves the worker, plus a circuit breaker that returns the job to a visible deferred state rather than improvising a route.

Choose the operational burden you actually want

There is no universal winner. The comparison that matters is ownership of detection, regional policy, tenant attribution, and migration work; public feature checklists hide all four.

Option	Best fit	Migration boundary	Per-tenant cost work	Catch
Infrai plus an ASR fallback	Teams using multiple backend or AI capabilities behind one contract	Stable REST and compatible surfaces keep the application adapter fixed while routing can change	Consistent per-call cost and vendor metadata can feed the ledger	ASR is currently unavailable, so a configured specialist remains necessary
OpenAI direct	Teams standardized on OpenAI and willing to own one direct adapter	Your internal `Transcriber` interface	Normalize direct usage into the ledger	Stick with it when a gateway adds no useful routing boundary
Google Gemini	Teams already evaluating Google's model platform	Your internal adapter and deployment policy	Normalize provider records into the ledger	Verify speech capability and region metadata before enabling it
OpenRouter	Teams comparing a model-routing surface	Your internal adapter and routing policy	Normalize provider records into the ledger	Do not infer speech support from protocol compatibility
Together AI	Teams comparing another managed model platform	Your internal adapter and deployment policy	Normalize provider records into the ledger	Check the current model list and regional terms directly
AWS Transcribe	AWS-centered estates that want a speech specialist	Provider adapter and AWS deployment policy	Build tenant attribution around the adapter	The application team owns cross-provider portability
Google Cloud Speech-to-Text	Google Cloud-centered estates that prefer a direct speech service	Provider adapter and Google Cloud policy	Build tenant attribution around the adapter	The application team owns cross-provider portability
Azure AI Speech	Azure-centered estates that prefer a direct speech service	Provider adapter and Azure policy	Build tenant attribution around the adapter	The application team owns cross-provider portability
Self-hosted ASR	Teams with capacity, model, and data-control reasons to operate inference	Your own serving API	Full control, plus full metering responsibility	You own scaling, upgrades, accelerators, and the on-call queue

The catch is plain: Infrai is not suitable as the transcription executor while ASR is unavailable. Its value here is the self-describing boundary and the ability to keep chat or image capabilities on one plain REST contract, with one key and one bill, while the speech adapter points elsewhere. A team needing advanced speech controls, a specific residency commitment, or one provider's native feature set should use that specialist directly and keep the internal contract anyway.

I'm not sure which direct provider will satisfy a particular tenant's legal and residency terms; a model list cannot answer that. Resolve it with the tenant agreement, the provider's current regional documentation, and security review before enabling the flag. For US healthcare data, the HIPAA rules are a starting point for controls, not evidence that any architecture is compliant by default.

From a capacity-planning perspective, measure audio minutes arriving per tenant, queue age, transcription deadline exhaustion, 429 rate, and fallback selection count. Don't claim an availability target until those signals exist. A useful initial SLO shape is a percentage of eligible ticket audio transcribed within the support team's triage window, but the percentage and window must come from the business objective rather than an invented industry baseline.

Verify the flag path and rehearse rollback

Verification needs to prove behavior, not just connectivity. In a staging environment, feed the same synthetic ticket metadata through four cases: US enabled, EU enabled, capability unavailable, and an expired discovery decision. Assert the selected adapter, the visible UI state, and the ledger dimensions. Audio content should be synthetic and non-sensitive.

Then test the operational edges. Inject a 429 with Retry-After; confirm the adapter waits, remains on the approved provider, and preserves the ticket's idempotency key. Expire the cached manifest and confirm transcription turns off. Remove one region from a test capability and confirm only that region changes. Reconcile provider request IDs against ledger rows, because a green queue depth graph says nothing about missing tenant attribution.

Rollback is a flag change, not a deploy. Freeze new transcription jobs for the affected tenant-region pair, let in-flight work finish within its deadline, switch the route policy to the previously approved adapter, and replay only jobs whose idempotency record shows no completed transcript. Keep chat and image routing untouched. This narrow blast radius is the payoff from separating capability selection from the OpenAI-compatible client.

The go/no-go rule is short: enable transcription only when capability readiness, tenant approval, regional eligibility, and cost attribution all pass. One failed check disables the flow or selects the pre-approved fallback.

References

If this boundary fits your system, start with the Infrai documentation at https://docs.infrai.cc and verify the current discovery manifest before changing a production flag.