My Solution for Design a Digital Wallet

by nectar4678

System requirements


Functional:

User Registration and Login:

  • Users must be able to register using their email, phone number, or social media accounts.
  • Secure login using password, biometric authentication, or OTP.

Account Management:

  • Users can view and update their account details.
  • Users can set preferences for notifications, security settings, and linked accounts.

Wallet Management:

  • Users can store digital money in their wallet.
  • Users can view their wallet balance.
  • Users can add or withdraw funds from their wallet using various payment methods (credit/debit cards, bank transfers, etc.).

Transactions:

  • Users can make online payments to merchants.
  • Users can make offline payments using QR codes or NFC.
  • Users can send and receive money to/from other users.
  • Users can view transaction history and details.

Payment Gateway Integration:

  • Integration with multiple payment gateways for processing transactions.
  • Integration with banking systems for fund transfers.

Notifications:

  • Users receive notifications for successful/failed transactions, low balance, and other critical actions.

Security:

  • Two-factor authentication for critical actions (e.g., adding a new payment method, large transactions).
  • Regular security audits and updates.


Non-Functional:

Scalability:

  • The system must handle up to 1 million daily active users.
  • The system should support 200,000 concurrent users.

Performance:

  • The system should process transactions within 2 seconds.
  • The system should have high availability with an uptime of 99.99%.

Security:

  • Data encryption at rest and in transit.
  • Compliance with financial regulations (e.g., PCI-DSS).

Usability:

  • Intuitive user interface for easy navigation.
  • Accessible on multiple devices (web, mobile).

Maintainability:

  • Modular codebase for easy updates and maintenance.
  • Comprehensive logging and monitoring for issue detection and resolution.

Interoperability:

  • Seamless integration with external payment gateways and banking systems.



Capacity estimation

Assumptions

  • Daily Active Users (DAU): 1 million users.
  • Transactions per User per Day: 10 transactions.
  • Peak Concurrency: 20% of DAUs active concurrently.
  • API Calls per Transaction: 5 API calls (authentication, authorization, transaction processing, notification, and logging).


Calculations

Total Transactions per Day:

  • Total Transactions = DAU × Transactions per User
  • Total Transactions = 1,000,000 × 10 = 10,000,000 transactions/day

Total API Calls per Day:

  • Total API Calls = Total Transactions × API Calls per Transaction
  • Total API Calls = 10,000,000 × 5 = 50,000,000 API calls/day

Peak Concurrency:

  • Peak Concurrent Users = DAU × Peak Concurrency Percentage
  • Peak Concurrent Users = 1,000,000 × 20% = 200,000 users

Peak Transactions per Second (TPS):

  • Assuming peak hours are 10% of the day (2.4 hours or 8,640 seconds).
  • Peak Transactions = Total Transactions × 10%
  • Peak Transactions = 10,000,000 × 10% = 1,000,000 transactions during peak hours
  • Peak TPS = Peak Transactions / Peak Hours in Seconds
  • Peak TPS = 1,000,000 / 8,640 ≈ 116 TPS

Peak API Calls per Second (APS):

  • Peak API Calls = Total API Calls × 10%
  • Peak API Calls = 50,000,000 × 10% = 5,000,000 API calls during peak hours
  • Peak APS = Peak API Calls / Peak Hours in Seconds
  • Peak APS = 5,000,000 / 8,640 ≈ 579 APS


Infrastructure Requirements

Based on the above calculations, we need to ensure the infrastructure can handle:

  • Daily Transactions: 10 million transactions
  • Daily API Calls: 50 million API calls
  • Peak TPS: 116 transactions per second
  • Peak APS: 579 API calls per second


Database Capacity

Transaction Data Storage:

  • Average size of a transaction record: 1 KB
  • Daily Data Ingress = Total Transactions × Size per Transaction
  • Daily Data Ingress = 10,000,000 × 1 KB = 10 GB/day

User Data Storage:

  • Average size of a user record: 10 KB
  • Total User Data = DAU × Size per User
  • Total User Data = 1,000,000 × 10 KB = 10 GB

Total Storage Requirements:

  • Assume data retention for 1 year.
  • Total Annual Transaction Data = Daily Data Ingress × 365
  • Total Annual Transaction Data = 10 GB × 365 = 3.65 TB
  • Total Storage = User Data + Annual Transaction Data
  • Total Storage = 10 GB + 3.65 TB ≈ 3.66 TB


Network Bandwidth

API Call Size:

  • Average size of an API call (request + response): 2 KB

Total Daily Bandwidth:

  • Total Daily Bandwidth = Total API Calls × Size per API Call
  • Total Daily Bandwidth = 50,000,000 × 2 KB = 100 TB/day


Conclusion

  • Storage: Minimum of 3.66 TB storage.
  • Compute: Capacity to handle 116 TPS and 579 APS.
  • Network: Bandwidth to handle 100 TB/day.


API design

User Registration and Authentication

Register User

Endpoint: POST /api/v1/users/register Request: {   "email": "[email protected]",   "password": "securepassword",   "phone": "+1234567890",   "name": "John Doe" } Response: {   "userId": "12345",   "message": "User registered successfully" }


User Login

Endpoint: POST /api/v1/users/login Request: {   "email": "[email protected]",   "password": "securepassword" } Response: {   "token": "jwt-token-here",   "userId": "12345",   "message": "Login successful" }


Account Management

Get User Profile

Endpoint: GET /api/v1/users/{userId} Response: {   "userId": "12345",   "email": "[email protected]",   "phone": "+1234567890",   "name": "John Doe",   "preferences": {     "notifications": true,     "securitySettings": {       "2FA": true     }   } }


Update User Profile

Endpoint: PUT /api/v1/users/{userId} Request: {   "phone": "+0987654321",   "name": "John Doe Updated",   "preferences": {     "notifications": false,     "securitySettings": {       "2FA": false     }   } } Response: {   "message": "User profile updated successfully" }


Wallet Management

Get Wallet Balance

Endpoint: GET /api/v1/wallets/{userId}/balance Response: {   "userId": "12345",   "balance": 1500.00,   "currency": "USD" }


Add Funds to Wallet

Endpoint: POST /api/v1/wallets/{userId}/add Request: {   "amount": 500.00,   "currency": "USD",   "paymentMethod": "credit_card",   "paymentDetails": {     "cardNumber": "4111111111111111",     "expiryDate": "12/25",     "cvv": "123"   } } Response: {   "transactionId": "txn12345",   "userId": "12345",   "amount": 500.00,   "currency": "USD",   "balance": 2000.00,   "message": "Funds added successfully" }


Withdraw Funds from Wallet

Endpoint: POST /api/v1/wallets/{userId}/withdraw Request: {   "amount": 200.00,   "currency": "USD",   "paymentMethod": "bank_transfer",   "bankDetails": {     "accountNumber": "9876543210",     "bankName": "Bank Name",     "routingNumber": "110000000"   } } Response: {   "transactionId": "txn67890",   "userId": "12345",   "amount": 200.00,   "currency": "USD",   "balance": 1800.00,   "message": "Funds withdrawn successfully" }


Transactions

Send Money to Peer

Endpoint: POST /api/v1/transactions/send Request: {   "senderId": "12345",   "receiverId": "67890",   "amount": 100.00,   "currency": "USD",   "note": "Payment for lunch" } Response: {   "transactionId": "txn11223",   "senderId": "12345",   "receiverId": "67890",   "amount": 100.00,   "currency": "USD",   "balance": 1700.00,   "message": "Money sent successfully" }


Get Transaction History

Endpoint: GET /api/v1/transactions/{userId} Response: {   "userId": "12345",   "transactions": [     {       "transactionId": "txn11223",       "type": "send",       "amount": 100.00,       "currency": "USD",       "date": "2024-07-06T12:34:56Z",       "status": "completed",       "note": "Payment for lunch"     },     {       "transactionId": "txn44556",       "type": "receive",       "amount": 150.00,       "currency": "USD",       "date": "2024-07-06T12:45:00Z",       "status": "completed",       "note": "Payment for groceries"     }   ] }


Notifications

Get Notifications

Endpoint: GET /api/v1/notifications/{userId} Response: {   "userId": "12345",   "notifications": [     {       "notificationId": "notif123",       "type": "transaction",       "message": "Your payment of $100.00 to user 67890 was successful.",       "date": "2024-07-06T12:34:56Z",       "read": false     },     {       "notificationId": "notif456",       "type": "security",       "message": "Your account password was changed successfully.",       "date": "2024-07-06T12:45:00Z",       "read": true     }   ] }


Mark Notification as Read

Endpoint: POST /api/v1/notifications/{userId}/read Request: {   "notificationId": "notif123" } Response: {   "message": "Notification marked as read" }



Database design

  • User: Stores user account details.
  • Wallet: Stores balance and currency for each user.
  • Transaction: Stores all transaction details linked to a wallet.
  • Payment Method: Stores various payment methods linked to a user.
  • Notification: Stores notifications for the user.



High-level design

The high-level design of the digital wallet system will include the following main components:

  1. User Interface (UI): Provides the user with an interface to interact with the digital wallet system.
  2. Authentication Service: Handles user authentication and authorization.
  3. Account Management Service: Manages user accounts and profile settings.
  4. Wallet Service: Manages the user's digital wallet, including balance, transactions, and payment methods.
  5. Transaction Service: Handles sending, receiving, and processing transactions.
  6. Payment Gateway Integration: Integrates with external payment gateways and banking systems for processing payments.
  7. Notification Service: Sends notifications to users about their transactions and account activities.
  8. Database: Stores all user, wallet, transaction, payment method, and notification data.
  9. API Gateway: Routes API requests to the appropriate services and handles load balancing.




Request flows

User Registration Flow

  1. User submits registration details via the UI.
  2. The request is sent to the API Gateway.
  3. The API Gateway forwards the request to the Account Management Service.
  4. The Account Management Service validates and creates a new user record in the Database.
  5. The Account Management Service responds with a success message.
  6. The API Gateway forwards the response to the UI.


User Login Flow

  1. User submits login credentials via the UI.
  2. The request is sent to the API Gateway.
  3. The API Gateway forwards the request to the Authentication Service.
  4. The Authentication Service validates the credentials and issues a JWT token.
  5. The Authentication Service responds with the token.
  6. The API Gateway forwards the response to the UI.


Adding Funds to Wallet Flow

  1. User initiates adding funds via the UI.
  2. The request is sent to the API Gateway.
  3. The API Gateway forwards the request to the Wallet Service.
  4. The Wallet Service processes the request and interacts with the Payment Gateway Integration.
  5. The Payment Gateway Integration processes the payment and confirms the fund transfer.
  6. The Wallet Service updates the wallet balance in the Database.
  7. The Wallet Service responds with the updated balance.
  8. The API Gateway forwards the response to the UI.


Sending Money to Peer Flow

  1. User initiates sending money via the UI.
  2. The request is sent to the API Gateway.
  3. The API Gateway forwards the request to the Transaction Service.
  4. The Transaction Service processes the transaction and updates the sender's and receiver's wallet balances in the Database.
  5. The Transaction Service responds with the transaction details.
  6. The API Gateway forwards the response to the UI.


Receiving Notifications Flow

  1. User requests notifications via the UI.
  2. The request is sent to the API Gateway.
  3. The API Gateway forwards the request to the Notification Service.
  4. The Notification Service retrieves notifications from the Database.
  5. The Notification Service responds with the notifications.
  6. The API Gateway forwards the response to the UI.


Detailed component design

Wallet Service

Responsibilities:

  • Manage wallet balance.
  • Handle adding and withdrawing funds.
  • Interface with payment gateways.

Scalability Considerations:

  • The Wallet Service must handle high volumes of concurrent requests, especially during peak hours.
  • Use horizontal scaling to manage load.
  • Implement caching to reduce database load for frequent balance checks.

Algorithms and Data Structures:

  • Concurrency Control: Use optimistic locking to handle concurrent updates to the same wallet balance.
  • Caching: Use Redis or a similar in-memory data store to cache wallet balances for quick access.



Transaction Service

Responsibilities:

  • Process send/receive transactions.
  • Ensure atomicity of transactions.
  • Maintain transaction history.

Scalability Considerations:

  • Transactions must be processed reliably and consistently.
  • Use database transactions to ensure atomicity.
  • Implement sharding for the transaction database to handle high write throughput.

Algorithms and Data Structures:

  • Two-Phase Commit: Ensure that both the sender's and receiver's balances are updated atomically.
  • Transaction Log: Maintain a log of all transactions for audit purposes.



Notification Service

Responsibilities:

  • Send notifications for transactions and account activities.
  • Ensure timely delivery of notifications.

Scalability Considerations:

  • High throughput for sending notifications during peak times.
  • Use message queues for handling large volumes of notifications.
  • Implement retry mechanisms for failed notification deliveries.

Algorithms and Data Structures:

  • Message Queue: Use RabbitMQ, Kafka, or similar for managing notification tasks.
  • Retry Mechanism: Implement exponential backoff for retrying failed notifications.




Trade offs/Tech choices

Trade-offs

Relational vs. NoSQL Database

  • Choice: Relational Database (e.g., MySQL, PostgreSQL)
  • Reason: Financial transactions require ACID properties to ensure data consistency and reliability. Relational databases provide strong transactional guarantees, which are critical for managing user balances and transactions.
  • Trade-off: NoSQL databases like MongoDB offer better scalability and flexibility but lack strong consistency guarantees, making them less suitable for financial data.


Caching Strategy

  • Choice: Use Redis for caching wallet balances and frequently accessed data.
  • Reason: Caching reduces database load and improves response times for balance checks and other frequent operations.
  • Trade-off: Caching introduces complexity in ensuring cache consistency with the database. Stale data in the cache can lead to inconsistencies if not properly managed.


Optimistic Locking vs. Pessimistic Locking

  • Choice: Optimistic Locking for wallet balance updates.
  • Reason: Optimistic locking allows for better performance under high concurrency by reducing the time locks are held on resources. This is suitable for scenarios with infrequent write conflicts.
  • Trade-off: Optimistic locking may result in higher retry rates under heavy contention, which could affect performance. Pessimistic locking, while reducing retries, could lead to increased contention and deadlocks.


Technology Choices

Backend Framework: Spring Boot (Java) or Node.js (JavaScript)

  • Reason: Both frameworks offer strong support for building scalable microservices, extensive libraries, and community support. Spring Boot is chosen for its robust features in enterprise applications, while Node.js is chosen for its lightweight and non-blocking I/O operations.


Message Queue: RabbitMQ or Apache Kafka

  • Reason: RabbitMQ is suitable for reliable message delivery and supports complex routing. Kafka is chosen for its high throughput and scalability, making it suitable for handling large volumes of notification tasks.


API Gateway: Kong or AWS API Gateway

  • Reason: Both provide robust features for managing API traffic, including rate limiting, load balancing, and authentication. Kong is chosen for its open-source nature and flexibility, while AWS API Gateway is chosen for seamless integration with other AWS services.



Failure scenarios/bottlenecks

Database Failures

Scenario: The primary database goes down or becomes unavailable.

Mitigation:

  • Replication: Use database replication (master-slave or master-master) to ensure a standby database is available.
  • Automatic Failover: Implement automatic failover mechanisms to switch to a standby database in case of primary database failure.
  • Backups: Regularly back up the database and test the restoration process to ensure data can be recovered.



Cache Inconsistency

Scenario: The cache contains stale or inconsistent data compared to the database.

Mitigation:

  • Cache Expiry: Set appropriate TTL (Time-to-Live) values for cache entries to ensure periodic refresh.
  • Cache Invalidation: Implement cache invalidation strategies to update or remove stale data upon database updates.
  • Write-Through Cache: Use write-through caching to update the cache and database simultaneously.



 Payment Gateway Integration Failures

Scenario: Payment gateway integration fails, causing transactions to be unsuccessful.

Mitigation:

  • Retry Mechanism: Implement retry logic with exponential backoff for transient failures.
  • Fallback Gateways: Integrate with multiple payment gateways to switch to an alternative in case of failure.
  • Transaction Logging: Log all transaction attempts for audit and reconciliation purposes.



Future improvements

Enhanced Security Measures

  • Implement AI-based fraud detection to identify suspicious activities in real-time.
  • Use hardware security modules (HSM) for secure key management and cryptographic operations.
  • Enable biometric authentication methods such as fingerprint and facial recognition.


Improved Scalability

  • Implement auto-scaling across all services to handle sudden spikes in traffic.
  • Use serverless architectures for specific workloads to achieve better scalability and cost-efficiency.
  • Adopt container orchestration platforms like Kubernetes for efficient resource management and scaling.


Advanced Data Analytics

  • Integrate data analytics platforms to gain insights into user behavior and transaction patterns.
  • Use machine learning models to predict user needs and offer personalized services.
  • Implement real-time analytics to monitor system performance and user interactions.


Interoperability with Other Financial Services

  • Integrate with more financial institutions and services to offer a wider range of payment options.
  • Enable support for cryptocurrencies and blockchain-based transactions.
  • Develop open APIs to allow third-party developers to build applications and services on top of the digital wallet platform.