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. **Real-time Payment Processing:** The system should process payments in real-time with a maximum latency of 100ms.
2. **Support Multiple Payment Methods:** The system must handle credit cards, bank transfers, and digital wallets.
3. **User Notifications:** Send instant notifications to users upon successful or failed transactions.
4. **Transaction History:** Allow users to view their transaction history with filters for date and amount.
5. **Fraud Detection:** Implement basic anomaly detection for unusual transaction patterns.

### Non-Functional Requirements:
1. **Scalability:** The system should handle up to 10,000 transactions per second (TPS) at peak times.
2. **Availability:** Aim for 99.99% uptime, incorporating failover mechanisms.
3. **Security:** Adhere to PCI DSS compliance for payment processing.
4. **Data Consistency:** Ensure eventual consistency for non-critical data while maintaining strong consistency for critical payment transactions.

Assuming peak usage occurs during business hours, we estimate:
- **Users:** 1 million active users at peak.
- **Transactions:** Each user may initiate an average of 10 transactions per hour.
- **Total TPS at peak:**
   - 1,000,000 users * 10 transactions/hour / 3600 seconds = ~2778 TPS.
   - To accommodate bursts, we plan for 10,000 TPS.

### Data Storage Requirements:
- **Transaction Records:** Assume each transaction record is 1KB. For 10,000 TPS over 24 hours:
   - 10,000 TPS * 86400 seconds = 864,000,000 transactions/day.
   - Total storage = 864,000,000 * 1KB = ~800GB/day.
   - Retaining for one year leads to ~292TB for transaction logs.

### Component Diagram:
- **API Gateway (AWS API Gateway):** Handles incoming requests and rate limiting.
- **Load Balancer (AWS ELB):** Distributes requests across multiple application servers.
- **Application Servers (Node.js):** Handle business logic and payment processing.
- **Payment Processor Integration:** Integrate with external payment gateways (Stripe, PayPal).
- **Cache Layer (Redis):** For frequently accessed data like user details and transaction history.
- **Database (PostgreSQL):** For transaction storage, leveraging partitioning for performance.
- **Monitoring (Prometheus + Grafana):** For performance metrics and alerting.
- **Message Queue (Kafka):** For asynchronous processing of notifications and fraud detection alerts.

### Database Schema Design:
1. **Users Table:**
   - `user_id` (PK, UUID), `name` (String), `email` (String), `created_at` (Timestamp)
2. **Transactions Table:**
   - `transaction_id` (PK, UUID), `user_id` (FK, UUID), `amount` (Decimal), `status` (Enum: 'PENDING', 'COMPLETED', 'FAILED'), `created_at` (Timestamp)
3. **Notifications Table:**
   - `notification_id` (PK, UUID), `user_id` (FK, UUID), `transaction_id` (FK, UUID), `message` (String), `sent_at` (Timestamp)

### Access Patterns:
- Frequent reads for transaction history and user notifications, necessitating appropriate indexing and caching strategies.

### Architectural Decisions:
1. **Consistency vs Availability:** Opting for eventual consistency in transaction history to enhance availability, but ensuring strong consistency for payment transactions to prevent double spending.
2. **Database Choice:** PostgreSQL offers ACID compliance, which is critical for transactional integrity, but may introduce latency compared to NoSQL options. The choice is justified given the requirement for strong consistency.
3. **Caching Strategy:** Using Redis for caching reduces read latency for frequently accessed data but introduces complexity in cache invalidation strategies, especially for user data.
4. **Latency Handling:** Prioritizing low latency may lead to increased complexity in the architecture, especially with asynchronous processing. Ensuring that critical paths are optimized while offloading non-critical tasks to background processes like Kafka is key.
5. **Security Measures:** Implementing strict security measures such as token-based authentication adds overhead but is necessary for compliance and protecting sensitive data.

Design a low-latency Payment System

Morgan Stanley

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

Morgan Stanley 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