Design credit card system:
Requirements:
• apply for credit card application
• create and access bank account
• posting transactions using 3rd party API, view card balance, view transactions history
• handle credit card payment processing
• view daily, weekly, and monthly stats
Goal: complete all core features at minimum the HLD, and discuss improvments in deep dive if time is available
Assuming: design everything from scratch, except for the payment API. Focus on backend, and not UI design. UI, authentication, observability/logging, security can consider they are handled. Designing for average customer and not celebrities. Number estimates not necessary for now
Non Functional:
Scalable for 300 mil people, and just for US is ok (Local region, USD).
Highly consistent (ACID DB)
Highly reliable- no over charging, or lost payment information (tracking all activity before commiting to DB)
Due to CAP tradeoffs, second important but still as much availability as possible (< 10 hour outage a year)
Loading account, and transaction history should be fast (< 1 second)
Payments need to be secure, and suspicious activity should be rejected
API workflow:
CreateApplication(): client-> LB -> applicationsManagement service ->Process: store in queue and verify details -> notify if success or fail
Create/load account(): client-> LB -> DB for accounts table. DB sharded by userId
PostTransaction(): client -> LB -> transactionsManageService -> if success, go to DB and update account balance
ProcessPayment():
-Part 1: client-> Payment storage:
client makes new payment-> API gateway/LB -> payment service -> store payment event
-Part 2: PaymentEventStorage -> PaymentExecutor
-> store jobs for processing payment order in a queue, and update payments DB to track status of each payment order
DB MODEL using mySQL: orderID(Idempotency key), userId, LastUpdatedTime, order status = WAITING, SUCCESS, FAIL, PROCESSING
-> payment executor ( using Stripe for payment) -> stripe sends notification for completion message, and update DB STATUS = SUCCESS when done via pushing
UserPaymentActivityReportBuilding():
- Creating jobs for building report: have a service or job scheduler check for users that need payment activity generated, and add them to a queue for generating an activity report.
Reporting service pulls from this queue, creates report and stores in a DB:
Brute force: query DB for activity in the last month, week, day
Lambda architecture: We can use batching and mapreduce, but it's overkill for the amount of data we have
Real time: as payments activity come into Payment Order Kafka queue, and have a subscriber called Reporting Service pull from Kafka, aggregate the data, and write into the Reports DB. DB is can be Cassandra for all the report objects
ViewReport():
Users can load the website view on their app, and the report data is pulled from reports database
HLD:
User Interface (UI): Web and mobile app interfaces for seamless user experience.
API Gateway: Single entry point for all API requests, securing and controlling access.
Authentication Service: Handles user registration, login, and access control using robust mechanisms like OAuth.
Card Management Service: Manages credit card applications, account information, balance, and transaction history.
Payment Processing Service: Integrates with external payment gateways to securely process transactions.
Reporting Service: Aggregates and analyzes transaction data for generating daily, weekly, and monthly reports.
Database: Stores user data, account information, transactions, and other relevant data in a secure and scalable manner.
Deep dive: all components should be scalable, and have load balancers and without a single point of failure.
In case of failed requests, exponential backoff is used, and dead letter queues for major issues.
Every night for every user account, reconciliation jobs are ran for every user, to see if there are any issues caused in syncing, dropped request, or code problems by comparing event log activity with database values
Latency improved by caching static data, and for resilience all data is backed up and synced with the primary machine. Transactions database is write heavy, so Cassandra is a great way to handle the load, and another data base is used from querying and running read requests for viewing reports.
Tech stack used:
Stripe for Payments API
Kafka for payment executing queue, and also used to append user activity for each interval
MySql for ACID compliant DB
For payment events storage: scalable + quick queries via time series DB or NoSQL wide column like DynamoDb for fast queries by time stamp
For reports storage: MongoDb is popular for documents/object storage
For reporting service, Spark is a good way to automate reports generation off of Kafka
For security, we use Restful HTTPS, token based authentication, firewall for internal service