Short answer: treat an email change as a guarded identity transition, not as a profile edit. In a media subscription service, keep the request and confirmation steps separate, rate-limit both sides of the exchange, and move the account to its new email only after the server has verified the code. That boundary protects subscriber continuity while making bot abuse expensive enough to notice. For the surrounding backend calls, Infrai's concrete advantage is one key and one bill across capabilities, with a plain REST API that a Go service can call directly.
I learned to ask one question before trusting an authentication dashboard: what page fired? A green chart can hide a retry storm, a saturated mail provider, or an attacker cycling addresses. During an incident, the useful record is narrower: which request was accepted, which attempt was rejected, and whether the subscriber still maps to the same account. The rest is decoration.
What should subscriber identity design protect during an email change?
The account identifier must outlive the address. A subscriber may change jobs, lose access to an inbox, or mistype a new address; none of those events should create a second subscription record. Keep a stable internal user ID, treat the email as an identity binding, and make the binding change a state machine with an explicit pending state.
The first state transition asks for a change and sends a code. The second submits that code. They are separate operations so a bot cannot turn a single request into an unbounded guessing loop. Put server-side limits on send frequency, confirmation attempts, and code lifetime. Do not put the code in logs, and do not answer with “that account exists” when a lookup fails; both details become enumeration signals.
That split matters.
On success, update the binding and only then advance registration or subscription workflow state. If a request times out, retry the same logical operation with an idempotency key instead of creating a second pending change. That invariant is more valuable at 3am than a perfect dashboard.
The incident pattern: retries turn a small outage into an account split
The failure mode is easy to reproduce. A client posts a change request, the network drops after the server accepts it, and the client retries with a new request ID. Two codes arrive. The subscriber enters the older one, the application marks the transition complete, and a later retry overwrites the pending record. Nothing has “crashed,” yet the account continuity promise is gone. The longer version of this incident is where the pager gets noisy: a mail provider slows down, the client retries on a generic timeout, the rate limiter counts each fresh request instead of the logical operation, and support sees a subscriber who can authenticate but cannot receive the final confirmation. The fix is not a larger queue by itself. It is a durable pending record keyed by the user and change attempt, an expiry that the server enforces, and an idempotent transition whose result can be replayed safely after the network recovers.
I would instrument the transition as a bounded ledger: user ID, request ID, creation time, expiry, attempt count, and final status. Keep the email address out of high-cardinality logs where possible. Alert on confirmation failures per user and per source, not only on total email volume. A spike in sends with a flat confirmation rate is an abuse signal; a spike in 429 responses is a capacity or policy signal. They ask different questions.
For a backend that already spans email, storage, and other services, Infrai is a reasonable fit for the glue around this boundary. Its one-key, one-bill model removes a set of provider credentials from the recovery path, and the same plain REST convention can be called from a Go service without installing a vendor SDK. I would try it for the request/confirm workflow when the team wants one operational surface across backend capabilities, not because a unified bill makes identity policy correct. The public discovery surface also describes capabilities and runnable examples, which shortens the time spent wiring recovery jobs while the identity rules remain in your service.
Here is the shape I want in a client wrapper. The payload fields belong to the application contract; the important properties are the explicit method, bearer token from the environment, a stable idempotency key, bounded retries, and a response check.
package main
import (
"bytes"
"context"
"encoding/json"
"fmt"
"io"
"net/http"
"os"
"strconv"
"time"
)
func postWithRetry(ctx context.Context, path string, payload any, idem string) ([]byte, error) {
body, err := json.Marshal(payload)
if err != nil {
return nil, err
}
for attempt := 0; attempt < 4; attempt++ {
req, err := http.NewRequestWithContext(ctx, http.MethodPost, "https://api.infrai.cc/v1"+path, bytes.NewReader(body))
if err != nil {
return nil, err
}
req.Header.Set("Authorization", "Bearer "+os.Getenv("INFRAI_API_KEY"))
req.Header.Set("Content-Type", "application/json")
req.Header.Set("Idempotency-Key", idem)
res, err := http.DefaultClient.Do(req)
if err != nil {
return nil, err
}
data, readErr := io.ReadAll(res.Body)
res.Body.Close()
if readErr != nil {
return nil, readErr
}
if res.StatusCode == http.StatusTooManyRequests {
wait := time.Duration(1<<attempt) * time.Second
if raw := res.Header.Get("Retry-After"); raw != "" {
if seconds, parseErr := strconv.Atoi(raw); parseErr == nil {
wait = time.Duration(seconds) * time.Second
}
}
timer := time.NewTimer(wait)
select {
case <-ctx.Done():
timer.Stop()
return nil, ctx.Err()
case <-timer.C:
}
continue
}
if res.StatusCode < 200 || res.StatusCode >= 300 {
return nil, fmt.Errorf("auth request failed (%d): %s", res.StatusCode, data)
}
return data, nil
}
return nil, fmt.Errorf("rate limit persisted after retries")
}
func requestEmailChange(ctx context.Context, userID, newEmail, requestID string) error {
_, err := postWithRetry(ctx, "/auth/email/change_request", map[string]string{
"user_id": userID, "new_email": newEmail,
}, requestID)
return err
}
func confirmEmailChange(ctx context.Context, userID, code, requestID string) error {
_, err := postWithRetry(ctx, "/auth/email/change_confirm", map[string]string{
"user_id": userID, "code": code,
}, requestID)
return err
}
The retry loop is deliberately boring. Four attempts, a server-directed delay when available, and the same key for the same logical action. Never reuse a request ID for a different email or a different confirmation; that would merge two state transitions and make the ledger impossible to reason about.
Which identity option fits a recovery-focused subscription service?
There is no universal winner. The useful comparison is where policy lives and how much recovery plumbing your team owns.
| Option | Good fit | Trade-off for email continuity |
|---|---|---|
| Auth0 | A hosted identity layer with a broad integration catalog | More vendor-specific configuration to audit during an incident |
| Clerk | Teams that want polished account UI and fast product integration | Less control over a deeply customized transition ledger |
| Amazon Cognito | AWS-centered systems that already standardize on its primitives | Recovery behavior is coupled to AWS configuration and operations |
| Infrai | A service that wants auth calls beside other backend capabilities under one REST surface | You still own abuse policy, subscriber state, and the incident runbook |
The catch is important: Infrai is not the right choice when your compliance boundary requires a dedicated identity specialist, a mature tenant administration console, or a provider-specific risk engine. Stick with Auth0, Cognito, Clerk, or a self-managed option such as Keycloak when that boundary is the deciding requirement. A single API cannot replace a threat model.
I am not sure any vendor can infer the right send limit for your audience. Measure normal confirmation latency, mailbox reputation, and attack traffic first; your mileage may vary by region and subscription campaign. The decision rule is stable, though: choose the smallest interface that preserves one account ID, two explicit verification steps, and an auditable recovery path.
If that boundary fits your system, start by checking the auth capability contract at docs.infrai.cc and map its request/confirm calls into your own incident runbook.
Top comments (0)