Design a User Login and Authentication System — System Design Interview Practice

Interview prompt

Design a secure identity service for registration, login, sessions, MFA, recovery, and token validation that resists abuse and remains available during dependency failures.

• Define the account lifecycle, password/KDF policy, session and refresh-token rotation, MFA challenges, recovery, and credential revocation.
• Protect against credential stuffing, enumeration, replay, fixation, CSRF, token theft, abuse of recovery, and compromised devices.
• Separate durable identity records from short-lived sessions and risk signals; make registration, login, and logout retries safe.
• Explain key rotation, auditability, privacy deletion, regional availability, observability, and safe failure behavior.

Requirements and scale assumptions

• Register and verify accounts, authenticate passwords or federated identities, issue/refresh/revoke sessions, and enforce MFA and device policy.
• Support password reset, email/phone change, account lock/risk challenges, logout-all, token introspection, and audit events.
• Provide idempotent requests, key rotation, rate limits, privacy export/deletion, and recovery when session or notification stores fail.
• Meet p95 login latency under 300ms while hashing passwords with an intentionally expensive memory-hard KDF.
• Scale to tens of millions of accounts and login bursts without a single hot key or unbounded synchronous work.
• Do not lose committed state; make retries and duplicate events safe.
• Degrade safely when downstream workers, caches, or external dependencies fail.
• 50M accounts and 20k login attempts per second during bursts
• Partition by the primary tenant, user, item, or geographic key and isolate hot partitions.
• Keep serving state bounded; retain raw events or durable records for replay and auditing.

• Peak scale: 50M accounts; 20k login attempts/s — Capacity assumption that drives partitioning and backpressure.
• Latency target: login p95 < 300ms; KDF enforced — User-facing budget for the primary request or read path.
• Durable boundary: Committed before async — The identity store and revocation records are authoritative; caches and sessions are bounded derivatives.
• Async boundary: At-least-once workers — Keep JWT or session tokens, Redis for session storage, Rate limiting per IP/user off the synchronous path.

Key entities

• ResourceSpecresourceId, tenantId, desiredState, version, policyVersion, updatedAt

  Versioned desired state for a user login and authentication system managed resource.

• OperationoperationId, resourceId, requestHash, step, attempt, status

  Durable user login and authentication system reconciliation operation with per-step progress.

• PolicyVersionpolicyId, scope, version, rules, effectiveAt, status

  Auditable user login and authentication system policy evaluated before provisioning or mutation.

• ReconciliationCheckpointresourceId, provider, observedVersion, cursor, lastError, updatedAt

  Provider-specific user login and authentication system observation and recovery cursor.

Data flow

1. 1. Accept a desired-state commandThe user login and authentication system control plane authenticates the tenant, validates policy and quotas, checks the expected version, and records the desired state.
2. 2. Plan a safe operationA planner turns user login and authentication system desired state into ordered, bounded steps with dependency checks, blast-radius limits, and rollback metadata.
3. 3. Reconcile providers asynchronouslyWorkers apply user login and authentication system operations through provider adapters, persist checkpoints, rate-limit calls, and treat unknown outcomes as observable state.
4. 4. Publish observed healthThe serving projection joins desired and observed user login and authentication system state with operation status, policy version, freshness, and actionable errors.
5. 5. Recover and auditRetries, dead letters, drift detection, and operator approvals repair user login and authentication system resources without losing the original command or provider evidence.

Deep dives and trade-offs

• Desired versus observed stateKeep user login and authentication system desired state separate from provider-observed state and show both to operators. Make every reconciliation step conditional and resumable so a worker crash does not restart unsafe effects. Version policy and resource state so old operations cannot overwrite newer intent.
• Provider failures and unknown outcomesUse provider-specific idempotency tokens and query-after-timeout behavior for user login and authentication system operations. Bound retries with exponential backoff, circuit breakers, and per-provider quotas. Route irreconcilable drift to an approval or quarantine path instead of retrying forever.
• Blast radius and operationsPartition user login and authentication system work by tenant, region, cluster, or resource class and cap concurrent mutations. Audit who changed desired state, which policy allowed it, and what provider evidence was observed. Alert on drift age, operation backlog, failed steps, policy denials, and stale observations.
• Push versus pull reconciliationUse event triggers for fast response and periodic scans for missed events, drift, and recovery. A push-only user login and authentication system controller silently misses changes when a provider event is lost.
• Central control plane versus provider-native controllersKeep policy, intent, and audit centralized while isolating provider-specific application logic behind adapters. A monolithic controller becomes hard to scale and couples unrelated provider failure domains.
• Automatic repair versus approvalAutomate low-risk, reversible user login and authentication system changes and require approval for destructive or high-blast-radius operations. Full automation without policy or blast-radius controls can turn a transient signal into a widespread outage.