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:

• Strong Consistency - reads should always reflect the latest written values
• High Availability (99.99%) - handles fault tolerance
• Horizontal Scaling - for handling increasing traffic
• Security - encrypts pii and able to audit transactions

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...

High-Level Design

Users can registers

Post /register

Body: {username/email, password, name}

Users can login

Post /auth/login

Body: {username/email, password}

Response: Jwt

Users can update/edit profile info

Patch /users/update

Authorization: Bearer

Body: {username/email, password, ...}

link bank accounts or payment methods

Post /link/accounts/new

Authorization: Bearer

Body: {account_number, routing_number}

Post /link/cards/new

Authorization: Bearer

Body: {name, card_number, exp_date, ccv}

Users can view transactions

Get /transactions

Authorization: Bearer

Users can see their balance - (it will shown in their account/profile)

Get /profile

Authorization: Bearer

track payment status

Get /payment/{payment_id}

Authorization: Bearer

get receipts for completed transfers

Get /receipts/{payment_id}

Authorization: Bearer

users can transfer money to other users (p2p)

Post /transfers

Authorization: Bearer

Body: {from_id, to_id, amount}

users can make payments (p2p, merchants)

Post /payments

Authorization: Bearer

Body: {from_id, to_id, amount}

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.

Architecture

Microservice architecture + services are stateless

API Gatway routes traffic to the individual service instances

via a service registry or service-level LB

DB

It will be a relational DB like Postgres because for transactional Systems

ACID transactions are extermely imporant. This because it prevent's partial

writes which helps concistency, locks allow for safe concurrency, and WAL allows

data be recoverable and never lost once it's written

Synchronous replicas will help with consistency & fault tolerance

For horizontal scalability we can shard the db using the user_id as the sharding key,

and the consistent hashing in order to reduce remapping when needing to increase/decrease shards

Bank Service

Will call the fraud service before commiting a transaction in order to determine whether to approve or reject the transaction

New transactions are commited with a status of pending

will handle all transfers, payments & withdrawls

Will use the kms in order to decrypt bank account or payment method info

Caching

User service can cache user profile data that doesn't change frequently, such as payment methods, settings, etc. Use the db as fallback on caches misses + update the cache

Bank service can cache recent user transactions. Use the db as fallback on caches misses + update the cache