Requirements
Functional Requirements:
- Allow users to send money or make payments to other users, merchants, or external accounts.
- Enable users to register accounts, log in, manage profiles, and link bank accounts or payment methods.
- Enable users to view past transactions, check balances, track payment status, and get receipts for completed transfers.
- Enable the system to detect and prevent fraudulent transactions in real time by analyzing transaction patterns, user behavior, and risk signals.
Non-Functional Requirements:
- High Availability (99.9% or more)
- Durability (no data loss)
- security / audit trail
- horizontal scalability
API Design
Define the APIs expected from the system. This is your chance to analyze and define the read and write paths so that you can come up with the high-level design...
Post /accounts
Body: {name, email, password, ...}
Post /login
Body: {email, password}
Get /accounts/{account_id}
Patch /update-account/{account_id}
Body: {email, address, ..}
Post /payment-methods/{account_id}
Body: {type, account_number, ...)
Post /transactions/{account_id}
Body: {type, amount, ..}
Get /transaction-history/{account_id}
Get /transactions/{account_id}/{transaction_id}
High-Level Design
Describe the overall system architecture. Identify the main components needed to solve the problem end-to-end. Use the diagramming tool to create a block diagram.
Client:
- User interface
API Gateway:
- Main entryway
- Routes traffic across the different services
- Handles token validation for security
- Handles Rate Limiting
Auth Service:
- Handles user logins
User Service:
- Handles user related tasks such as account creation & management
Banking Service:
- Handles Financial related tasks such as creating/viewing transaction
Fraud Detection Service:
- Handles fraud detection in both real time + long term user data analysis
Database:
- Relation database for persistent storage
- Uses synchronous replicas increased durability. The trade-off is speed
Keystore (KMS):
- Secure vault for master encryption keys
- Passively protects data at rest
- Generates data key + encrypted data key pair
- decrypt encrypted data key
LB:
- Data level load balancers distribute traffic across the multiple service instances
Detailed Component Design
Deep dive into 2-3 key components. Explain how they work, how they scale, discuss tradeoffs, capacity, and any relevant algorithms or data structures.
Entity Data Models
User
id (pk, unique, indexed)
name
email (unique, indexed)
password (indexed)
created_at (timestamp)
updated_at (timestamp)
last_login_geo_location
Transactions
- id (pk, unique, indexed)
- user_id (fk)
- payment_method_type
- payment_method_id
- amount
BankCard
- id (unique)
- user_id (fk)
- name
- number
- exp_date
- cvv
BankAccount
- id (unique)
- user_id (fk)
- account_number
- routing_number
Deep Dive / Detailed Component Designed:
- DB will be relational with synchronous replicas, to ensure
data durability, and make it fault tolerent
- User service will handle user related functions like
user creation, account management