Node.js Login Evidence — Beginner OTP 2FA Architecture with Email Fallback

A practical approach for a beginner Node.js 2FA login architecture involves sending the login code via SMS and providing an email fallback. Verify the code when the user submits it. For compliance, keep the authentication record separate from the notice-delivery record - logging that an administrator logged in doesn't prove that the notice reached the recipient.

Design the evidence boundary yourself, staying close to the provider boundary to minimize integration work. Retain a compact state transition record keyed by an internal attempt ID. Avoid storing message bodies, raw codes, phone numbers, or email addresses in routine telemetry. Keep detailed provider responses for a short operational window, but focus on normalized timestamps, channel, terminal state, and correlation identifiers in the longer audit record.

Consider the communications and observability charges. Poll delivery state only when necessary, as logging ingestion, indexed fields, retained event copies, and high-cardinality label queries can become burdensome. For a workload of 1 million authentication attempts per month, the raw volume could reach 4.5 GB before compression and indexing. Reducing record shape and cadence can significantly decrease raw monthly volume to around 700 MB.

Focus on the smallest defensible state machine: created, dispatched, verified, expired, and failed. For email code paths, generate, hash, expire, rate-limit, and verify the codes independently, while using the standard email-send operation for delivery. Treat the SMS and email paths as distinct with separate security measures.

Keep provider message identifiers behind the internal attempt ID, not as the primary business key. Use idempotency keys for retries to prevent duplicate sends due to network timeouts. Poll only attempts that remain nonterminal, apply backoff, and stop at a fixed deadline. Status reads can be small, inspectable HTTP calls, but ensure proper configuration of API_BASE_URL and MESSAGE_ID.

The compliance notice requires a separate record, including the version, intended recipient reference, send timestamp, provider correlation ID, and observed delivery state. While authentication and delivery may share a communications adapter, they should not share an audit assertion. The integration effort varies across different options, so focus on the application-owned boundary after the initial successful send.