A mixed delivery setup improves OTP reliability only when it separates failure domains; putting two providers behind one SMTP relay preserves a single point of failure. For a property marketplace, keep code creation and verification inside the authentication service, hand delivery to a channel-neutral dispatcher, and route each attempt through an independently authenticated path. The decisive metric is verified login completion before code expiry, not SMTP acceptance. A seller's new-order notice can wait or be retried. The login code that lets the seller act on that order cannot.
TL;DR: SMTP is a reasonable transport boundary for ordinary transactional mail, but a shared relay is the wrong abstraction for failover when its credentials, queue, network path, or routing rules are common to every provider. Use explicit per-path health, bounded failover, stable message correlation, and low-cardinality telemetry. Do not send the same valid code down several paths speculatively; duplicate arrivals create ambiguity and a wider exposure window without proving that the seller can complete login.
What reliability constraint does an order-triggered login create?
The marketplace event is straightforward: a new order arrives, the seller receives a notification, and an unauthenticated seller requests a one-time code. The reliability boundary is less straightforward. Order state, notification delivery, code verification, and the seller's eventual action are four different outcomes. Treating 250 accepted, an API success response, or a queue dequeue as "OTP delivered" collapses them into one optimistic number.
What should the system promise? It should promise one active verification state under its own control, bounded attempts, and a delivery strategy that does not change authentication semantics. The mail path may fail over; the verifier must not mint a second valid secret merely because the first provider was slow. Keep an idempotency key for the logical challenge and a separate attempt identifier for each delivery operation. That distinction lets an operator answer both "did this login challenge succeed?" and "which path handled attempt two?" without logging the code itself.
Short expiry creates a hard deadline rather than a generic throughput target. A delayed success after expiry is still a failed login experience. Conversely, retrying quickly can produce two messages that arrive out of order. The design therefore needs a small state machine: requested, dispatching, accepted, verified, expired, or exhausted. Provider responses remain evidence attached to a delivery attempt, not the authority on authentication state.
Should a mixed OTP email setup use one SMTP relay?
A topology diagram may show two vendors while the runtime still has one relay hostname, one credential store, one outbound network route, and one queue. Any failure in those shared components affects both nominal destinations. This is correlated failure disguised as redundancy.
SMTP also encourages a broad, transport-shaped contract: envelope, headers, body, and a success or error returned by the relay. A direct HTTPS mail interface can expose a different operational boundary, but changing protocols alone does not create independence. If both paths share DNS, secret rotation, deployment, throttling policy, or a dispatcher process with an unbounded queue, the system still has common-mode risk. The useful comparison is concrete:
| Design | Shared components | Failover signal | Main operational risk |
|---|---|---|---|
| One relay routing to several destinations | Relay, relay credentials, queue, routing policy | Relay-level status | A healthy downstream cannot bypass a failed relay |
| One dispatcher with independent SMTP connections | Dispatcher and policy; transport sessions are separate | Per-connection outcome | Dispatcher saturation can still affect every path |
| One dispatcher with independently authenticated HTTPS paths | Dispatcher and policy; credentials and requests are separate | Per-request outcome | Bad shared retry logic can amplify an outage |
| Separate workers and queues per path | Authentication challenge and routing policy only | Per-path queue age and outcome | More moving parts and more telemetry to govern |
This table does not make HTTPS inherently more reliable than SMTP. It shows where independence can be established and measured. An SMTP connection made directly to each destination can isolate more risk than a supposedly modern API architecture whose calls all pass through one broken gateway. Count shared dependencies, not provider logos.
Sender identity is another shared dependency. Yahoo's published sender guidance calls for authentication practices including SPF, DKIM, and DMARC, with additional requirements applying to bulk senders. A secondary delivery path that is not aligned with the same legitimate sending identity is not ready merely because its credentials work. Provisioning, DNS changes, and reputation need to happen before an incident, then be exercised under controlled traffic.
Observability should preserve decisions, not payloads
OTP telemetry becomes expensive and dangerous when every convenient field becomes a label. Email address, order ID, challenge ID, message ID, and error text are high-cardinality values. They belong in access-controlled event records only when retention and investigation needs justify them; they do not belong on every time-series metric. Never record the one-time code.
For metrics, a restrained label set is enough: path, stage, outcome, and a bounded reason_class. If there are 3 paths, 6 stages, 5 outcomes, and 8 reason classes, the full Cartesian ceiling is 720 series before environment and region are added. Adding a label with 50,000 seller values raises that theoretical ceiling to 36,000,000. This is cardinality arithmetic, not a traffic forecast, and it explains why seller identity must stay out of metric labels. Retention deserves the same explicit math. Suppose, as a planning example, an event record averages 900 bytes after indexing overhead and the service retains 2,000,000 delivery-attempt records each day. That is 1.8 GB per day, or 54 GB over a 30-day month before replication. The inputs must be measured in the actual logging system; the formula is the useful part. Reducing payload fields or shortening detailed retention often buys more than sampling rare failures. Sampling must follow the question being asked. Keep aggregate counters unsampled. Retain all authentication failures and all transitions into the fallback path for the short investigation window defined by the security and operations teams. Sample routine successes only after the counter has been emitted, and preserve a stable trace decision across the challenge so one login does not become a collection of unrelated fragments. A 1% random sample can describe common success latency; it is poor evidence for a rare, clustered failure that triggered failover.
No secrets. No vanity dimensions.
Compare paths by evidence from the same challenge
A useful evaluation starts with failure injection, not a feature matrix. Disable one credential, make one worker unavailable, delay one queue beyond the code deadline, and reject one class of recipient. For each test, observe whether the dispatcher moves to an eligible independent path, whether the verifier retains one logical challenge, and whether operators can reconstruct the decision without reading message content.
The retry budget should be intentionally small and deadline-aware. An attempt that cannot finish before expiry should not start. Retryable transport failure, permanent recipient rejection, and uncertain timeout need different policies; treating all three as "try the other provider" creates duplicates and may turn an invalid address into repeated traffic. The exact classifications depend on the interfaces selected, so they belong in an adapter contract with tests rather than scattered string matching.
Cost belongs in this review, but not as a quoted unit price. Each extra path adds credential rotation, sender-domain preparation, synthetic testing, on-call knowledge, and retained telemetry. Those are persistent operating costs. They are justified when an independently exercised path reduces a failure mode that matters to verified login completion, not when it merely makes the architecture diagram look redundant.
There is a real limitation: a mixed setup is not suitable when the team cannot operate and test two independent paths. In that case, one well-instrumented relay with a documented recovery procedure is the more honest design. Path isolation also cannot repair poor sender authentication, an incorrect recipient address, or a verifier outage; adding another delivery adapter to those failure modes increases operational surface without improving login completion.
More paths are not free.
The public documentation for one email API illustrates the HTTPS delivery shape, while Yahoo's sender guidance documents recipient-side expectations. Neither source can establish that a particular topology meets this marketplace's deadline. Only end-to-end tests using the marketplace's own challenge state, routing policy, and completion metric can do that.
Roll out the second path without changing auth semantics
Start by separating logical challenges from delivery attempts in the data model and dashboards. Next, run the additional path in shadow mode with synthetic messages to controlled recipients; do not send duplicate live codes. Validate authentication alignment and collect bounded path-level outcomes. Then allow a small cohort of live challenges to use the new path as the primary route, while the existing path remains available.
After both routes have operated independently, introduce deadline-aware fallback for narrowly classified transient failures. Set an automatic stop condition based on verified completion, duplicate-attempt rate, and queue age. Expand only when the new path improves the target outcome without creating unexplained second deliveries or an uncontrolled telemetry footprint.
The endpoint is modest: one challenge, a few observable attempts, and no shared component pretending to be redundancy. For a seller responding to a new property order, that is the architecture that makes a mixed setup meaningful.
References
The sources below support the email interface example and sender-authentication requirements. Architecture calculations and rollout criteria are derived explicitly in the article rather than attributed to a vendor.
Top comments (0)