Design a Payment Service

Question

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

Codemia · Accepted Answer

### Functional Requirements
1. **User Authentication**: Users must be able to create accounts, log in, and securely process payments.
2. **Payment Processing**: The system should process credit/debit card transactions, including authorization and capturing funds.
3. **Refunds and Chargebacks**: Support for processing refunds and managing chargeback requests.
4. **Transaction History**: Users should be able to view their payment and transaction history.
5. **Notifications**: Trigger notifications for successful payments, refunds, and payment failures.

### Non-Functional Requirements
1. **High Availability**: The system should be available 99.99% of the time.
2. **Scalability**: Must handle up to 10,000 transactions per second.
3. **Low Latency**: Transaction processing should complete within 2 seconds.
4. **Data Security**: Compliance with PCI-DSS for handling payment data securely.
5. **Error Handling**: Graceful handling of errors with informative responses for users and systems.

Assuming Datadog has a user base of around 10 million active users:
- **Daily Transactions**: If each user makes an average of 1 transaction per day, that's 10 million transactions.
- **Peak Load**: During peak hours (4 hours), let’s assume 50% of transactions occur, yielding approximately 125,000 transactions per minute or about 2,083 transactions per second.
- **Throughput Requirement**: To handle burst traffic, we should design for 10,000 QPS (Queries Per Second) to accommodate growth and peak loads.
- **Storage Requirements**: Assuming each transaction record is approximately 1 KB, for 10 million transactions daily, we would need about 10 GB of storage daily, requiring an architecture that can scale rapidly.

### Component Diagram
1. **API Gateway**: Acts as the entry point for all payment requests (AWS API Gateway).
2. **Microservices**: 
   - **Payment Service**: Handles transaction processing (Node.js with Express).
   - **User Service**: Manages user authentication and data (Java Spring Boot).
   - **Notification Service**: Sends notifications to users (Python with Celery).
3. **Database**: 
   - **Transactions Database**: NoSQL (MongoDB) to handle high write loads and flexible schemas.
   - **User Database**: SQL (PostgreSQL) for relational data with strong consistency.
4. **Message Queue**: (Kafka) for asynchronous processing of notifications and refunds.
5. **Cache**: Redis for caching frequently accessed data like transaction histories to reduce database load.

### Schema Design
1. **Transactions Collection (MongoDB)**:
   - `transaction_id`: String (PK)
   - `user_id`: String (FK)
   - `amount`: Decimal
   - `status`: String (e.g., "pending", "completed", "failed")
   - `created_at`: Timestamp
   - `updated_at`: Timestamp

2. **Users Table (PostgreSQL)**:
   - `user_id`: UUID (PK)
   - `email`: String (Unique)
   - `hashed_password`: String
   - `created_at`: Timestamp
   - `updated_at`: Timestamp

### Access Patterns
- Frequent reads from the Transactions collection for user transaction history.
- Writes are more frequent during peak transaction times, necessitating a NoSQL solution for fast writes.

1. **Consistency vs. Availability**: By using a NoSQL database for transactions, we sacrifice some strong consistency for higher availability and performance. We can implement eventual consistency for certain operations like user balances.
2. **Synchronous vs. Asynchronous Processing**: Choosing asynchronous processing for notifications and refunds allows the system to handle peak loads better but introduces complexity in ensuring messages are processed reliably.
3. **Database Choice**: The decision to use MongoDB for transactions allows for rapid scaling and flexibility but may complicate queries that require joins, which would be simpler in a SQL database.
4. **Caching Strategy**: Using Redis introduces additional complexity in cache invalidation but significantly improves read performance for user transaction histories.

Design a Payment Service

Datadog

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

Datadog 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