Build a Secure Identity Management Solution for Customers — System Design Interview Practice

Interview prompt

Design a customer identity platform for registration, social login, MFA, consent, conditional access, account recovery, and token issuance across multiple applications and tenants.

• Define the customer profile, verified identifiers, linked social identities, MFA factors, sessions, consent, risk, and tenant boundaries.
• Design secure journeys for signup, verification, login, recovery, consent, step-up MFA, account linking, and conditional access.
• Separate durable identity records from tokens, risk signals, notifications, and application claims; make external-provider retries safe.
• Explain enumeration resistance, credential abuse, key rotation, privacy deletion, auditability, regional recovery, and degraded behavior.

Requirements and scale assumptions

• Register and verify customers, authenticate local or social identities, issue tokens, enforce MFA/conditional access, and manage sessions.
• Support account linking, password reset, factor enrollment/revocation, consent, profile updates, logout-all, and application claims.
• Provide tenant isolation, audit events, deletion/export, provider outage handling, risk challenges, and idempotent recovery flows.
• Meet p95 token issuance under 500ms for healthy dependencies and fail closed for uncertain authorization decisions.
• Scale to 50M customers 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 customers, 10k tenants, and 25k authentication attempts per second at peak
• 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 customers; 25k auth attempts/s — Capacity assumption that drives partitioning and backpressure.
• Latency target: token p95 < 500ms; fail-closed auth — User-facing budget for the primary request or read path.
• Durable boundary: Committed before async — Customer identity, factor, consent, and revocation records are authoritative; tokens and risk caches are derived.
• Async boundary: At-least-once workers — Keep Azure AD B2C for customer identity, Custom policies for user journeys, MFA for security off the synchronous path.

Key entities

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

  Versioned desired state for a secure identity management solution managed resource.

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

  Durable secure identity management solution reconciliation operation with per-step progress.

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

  Auditable secure identity management solution policy evaluated before provisioning or mutation.

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

  Provider-specific secure identity management solution observation and recovery cursor.

Data flow

1. 1. Accept a desired-state commandThe secure identity management solution 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 secure identity management solution desired state into ordered, bounded steps with dependency checks, blast-radius limits, and rollback metadata.
3. 3. Reconcile providers asynchronouslyWorkers apply secure identity management solution 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 secure identity management solution state with operation status, policy version, freshness, and actionable errors.
5. 5. Recover and auditRetries, dead letters, drift detection, and operator approvals repair secure identity management solution resources without losing the original command or provider evidence.

Deep dives and trade-offs

• Desired versus observed stateKeep secure identity management solution 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 secure identity management solution 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 secure identity management solution 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 secure identity management solution 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 secure identity management solution 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.