Design a low-latency Payment System

Question

Design a low-latency payment system that handles millions of requests. Discuss trade-offs in consistency, availability, and performance.

Codemia · Accepted Answer

### Functional Requirements
1. **Transaction Processing**: The system must process payments in real-time, supporting credit/debit card transactions, bank transfers, and mobile payments.
2. **User Authentication**: Ensure secure user authentication before processing payments using OAuth or JWT.
3. **Transaction History**: Provide a way for users to view their transaction history, including status (success, pending, failed).
4. **Fraud Detection**: Implement mechanisms to detect and flag potentially fraudulent transactions.
5. **Webhook Notifications**: Support webhooks for notifying third-party systems about transaction statuses.

### Non-Functional Requirements
1. **Low Latency**: The system must respond to payment requests within 100 ms 95% of the time.
2. **Scalability**: The system should handle up to 10 million requests per day, with the ability to scale horizontally.
3. **Availability**: Aim for 99.99% uptime, even during peak traffic.
4. **Data Consistency**: Support eventual consistency for transaction records while ensuring strong consistency for user balance updates.

Assuming Anthropic expects to handle 10 million transactions per day:
- **Average Transactions per Second (TPS)**: 10 million transactions / 86,400 seconds = ~115 TPS.
- **Peak Load**: During peak hours (e.g., 5 PM to 9 PM), assume 40% of daily transactions occur:
  - Peak TPS = (10 million * 0.4) / (4 hours * 3600 seconds) = ~277 TPS.
- To accommodate spikes, we should provision for 2x peak load, targeting ~600 TPS. Thus, the system should handle high loads while maintaining performance.

### Component Diagram
The system can be designed with the following components:
1. **Load Balancer**: Distributes incoming requests across multiple application servers (Nginx or AWS ELB).
2. **Application Servers**: Stateless microservices built using Node.js or Go, responsible for processing payment requests.
3. **Database**: Use a distributed SQL database like CockroachDB for transactional consistency and scalability, with read replicas for load distribution.
4. **Cache Layer**: Use Redis to cache frequently accessed data like user balances and transaction statuses.
5. **Event Queue**: Kafka for handling asynchronous tasks like fraud detection and webhook notifications.
6. **Monitoring and Alerting**: Integrate Prometheus for monitoring and Grafana for visualization, setting up alerts for transaction failures or latency spikes.

### Schema Design
- **Users Table**: `user_id (PK), email, hashed_password, balance`
- **Transactions Table**: `transaction_id (PK), user_id (FK), amount, status (enum: pending, completed, failed), timestamp`
- **Fraud Alerts Table**: `alert_id (PK), transaction_id (FK), reason, timestamp`

### Access Patterns
- Frequent reads from the `Users` table to check balances during transactions.
- Write-heavy access on the `Transactions` table to log each payment attempt.
- Read from the `Fraud Alerts` table for monitoring and reporting purposes.

### Architectural Decisions
1. **Consistency vs. Availability**: Given the need for real-time processing, we opt for eventual consistency for transaction statuses but maintain strong consistency for user balances to avoid overspending.
2. **Database Choice**: Choosing CockroachDB provides horizontal scalability and strong consistency, but it may introduce latency compared to NoSQL databases under certain conditions. This trade-off is acceptable due to the need for transactional integrity.
3. **Cache Layer**: Implementing Redis for caching user balances can improve read performance but introduces complexity regarding cache invalidation. We need to carefully strategize updates to ensure users' balance views are accurate.
4. **Load Balancing**: While horizontal scaling increases fault tolerance and availability, it may introduce challenges in session management. Using stateless services helps mitigate this issue.

Design a low-latency Payment System

Anthropic

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

Anthropic 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