Design a Authentication Service

Question

Design a fault-tolerant authentication system that handles millions of requests. Discuss trade-offs in consistency, availability, and performance.

Codemia · Accepted Answer

### Functional Requirements
1. **User Registration**: Allow users to create accounts with email and password.
2. **User Login**: Enable users to authenticate using credentials.
3. **Session Management**: Provide session tokens for logged-in users to maintain authentication state.
4. **Password Reset**: Allow users to reset their passwords via email link.
5. **Multi-Factor Authentication (MFA)**: Support MFA for enhanced security.
6. **User Profile Management**: Allow users to update their personal details and security settings.

### Non-Functional Requirements
1. **Scalability**: The system must handle millions of requests per day, scaling horizontally as demand grows.
2. **Fault Tolerance**: The system should remain operational even during service disruptions.
3. **Performance**: Authentication should complete within 200ms under normal load.
4. **Security**: Strong encryption for passwords and tokens, adherence to OWASP security guidelines.
5. **Availability**: Aim for 99.99% uptime to ensure users can authenticate at any time.

Assuming **Cruise** has 10 million active users:
1. **Peak Load**: Estimating 5% of users log in concurrently during peak hours, that’s about 500,000 requests per hour or approximately 140 requests per second.
2. **Daily Requests**: Assuming an average of 2 logins per user per day, this results in 20 million login requests daily.
3. **Session Management**: Each active session could last around 1 hour, resulting in needing to handle 500,000 active sessions at peak.
4. **MFA Requests**: Assuming 30% of logins use MFA, that adds another 150,000 requests during peak.
5. **Total Requests**: Therefore, the system needs to handle around 290 requests per second during peak times for logins and MFA.

### Architecture Components
1. **API Gateway**: Use **NGINX** or **AWS API Gateway** to handle incoming requests and route them.
2. **Authentication Service**: A microservice built with **Spring Boot** for managing authentication logic.
3. **Database**: Use **PostgreSQL** for storing user credentials and profiles due to its robustness and support for ACID transactions.
4. **In-Memory Cache**: Implement **Redis** for caching user sessions and tokens to reduce database load and improve performance.
5. **Load Balancer**: Use **AWS ELB** to distribute incoming requests across multiple instances of the authentication service.
6. **MFA Service**: A dedicated service to handle MFA requests, integrated with SMS or email services (e.g., **Twilio**, **SendGrid**).

### Schema Design
1. **Users Table**:
   - `user_id` (PK, UUID)
   - `email` (unique, VARCHAR)
   - `password_hash` (VARCHAR)
   - `created_at` (TIMESTAMP)
   - `updated_at` (TIMESTAMP)
   - `mfa_enabled` (BOOLEAN)

2. **Sessions Table**:
   - `session_id` (PK, UUID)
   - `user_id` (FK, UUID)
   - `token` (VARCHAR)
   - `expires_at` (TIMESTAMP)

3. **MFA Tokens Table**:
   - `token_id` (PK, UUID)
   - `user_id` (FK, UUID)
   - `mfa_token` (VARCHAR)
   - `created_at` (TIMESTAMP)
   - `is_used` (BOOLEAN)

### Access Patterns
- Frequent reads from the Users table for authentication.
- Writes to the Sessions table upon login and session creation.
- Reads and writes to the MFA Tokens table during the MFA process.

### Architectural Decisions
1. **Consistency vs. Availability**: Prioritizing availability over strict consistency. Using eventual consistency for sessions can help maintain service availability during high loads.
2. **Caching Strategy**: Choosing Redis for caching sessions balances speed with the risk of stale data. Need to implement a TTL (time-to-live) for session data to ensure security.
3. **Database Choices**: While NoSQL databases like MongoDB could provide high write scalability, the need for strong consistency in user credentials leads to a decision in favor of PostgreSQL.
4. **Load Balancing**: Horizontal scaling of the authentication service can lead to complexity in managing state; hence, relying on stateless design principles where possible.
5. **Security Trade-offs**: Implementing MFA adds latency but significantly improves security. The decision balances user experience against potential security risks.

Design a Authentication Service

Cruise

What the Interviewer Expects

Key Topics to Cover

How to Approach This

Possible Follow-up Questions

Practice a Similar Problem on Codemia

Sample Answer

Requirements

Functional Requirements

Capacity Estimation

Submit Your Answer

Cruise Software Engineer Interview Guide

Related Questions

Design a high-throughput Inventory Management System

Design a low-latency Rate Limiting System

Design a fault-tolerant Payment System

Design a fault-tolerant Messaging System

Design Walmart Product Search