Build a high-throughput Authentication Pipeline

Question

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

Codemia · Accepted Answer

### Functional Requirements
1. **User Authentication**: The system must authenticate users via username/password, social logins, and multi-factor authentication (MFA).
2. **Session Management**: Support for session creation, validation, and expiration.
3. **Rate Limiting**: Enforce rate limits to prevent abuse and protect backend services.
4. **Audit Logging**: Log all authentication attempts, including successful and failed logins.
5. **API Access**: Expose RESTful APIs for authentication and user management.

### Non-Functional Requirements
1. **Scalability**: System should handle up to 10,000 QPS (queries per second).
2. **Availability**: Aim for 99.9% uptime with minimal downtime during maintenance.
3. **Performance**: Authentication should complete within 100 ms for 95% of requests.
4. **Security**: Ensure data is encrypted in transit and at rest, complying with standards such as GDPR.

### Back-of-Envelope Calculations
Assuming Neon serves 10 million active users and expects a peak load of 10,000 QPS:
- **Daily Requests**: 10,000 QPS * 86400 seconds = 864 million requests per day.
- **Storage Requirements**: Assuming each user authentication data takes 1 KB (including hashed passwords, session tokens, etc.), total storage for user data would be:
  - 10 million users * 1 KB/user = 10 GB for user data.
  - Logs (assuming 100 bytes per log entry): 864 million requests * 100 bytes/request = 86.4 GB per day.
- **Bandwidth**: If each request averages 200 bytes in response size, peak bandwidth = 10,000 requests/second * 200 bytes = 2 MB/s.

### Component Diagram
![High-Level Architecture](https://example.com/architecture-diagram)

1. **API Gateway**: Routes requests to appropriate microservices and handles rate limiting.
2. **Authentication Service**: Core service responsible for authenticating users.
3. **Session Store**: Redis for fast session management and storage of active sessions.
4. **User Database**: PostgreSQL for persistent user data and logs.
5. **Logging Service**: ELK stack (Elasticsearch, Logstash, Kibana) for centralized logging and monitoring.
6. **Load Balancer**: Distributes incoming authentication requests across multiple instances of the authentication service.

### Schema Design
1. **User Table**:
   - `user_id` (PK): UUID
   - `username`: VARCHAR
   - `password_hash`: VARCHAR
   - `email`: VARCHAR
   - `created_at`: TIMESTAMP
   - `updated_at`: TIMESTAMP

2. **Session Table**:
   - `session_id` (PK): UUID
   - `user_id` (FK): UUID
   - `expires_at`: TIMESTAMP
   - `ip_address`: VARCHAR

3. **Audit Log Table**:
   - `log_id` (PK): UUID
   - `user_id` (FK): UUID
   - `action`: VARCHAR
   - `timestamp`: TIMESTAMP
   - `status`: VARCHAR

### Access Patterns
- User data is fetched during login.
- Sessions are created and validated frequently, requiring fast access from the session store.

### Architectural Decisions
1. **Consistency vs Availability**: Opted for eventual consistency for session validation to improve availability during high loads. This means that a session might not be immediately invalidated on logout but will be eventually.
2. **Caching Strategies**: Using Redis for session storage to provide fast access while sacrificing some consistency since sessions might be stored in cache longer than intended.
3. **Database Choice**: Chose PostgreSQL for user data due to its support for complex queries and ACID compliance, balancing consistency and performance, while Redis handles ephemeral session data.
4. **Rate Limiting**: Implemented at the API Gateway level to prevent abuse, but this introduces the challenge of managing state across distributed instances. A distributed cache may be utilized to track request counts efficiently.

Build a high-throughput Authentication Pipeline

Neon

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

Back-of-Envelope Calculations

Submit Your Answer

Neon 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