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