Design an in-memory banking system
Design an In-Memory Banking System
Implement an in-memory banking system that supports various operations on user accounts. Assume user IDs are unique strings and monetary amounts are positive integers. The system is initially assumed to operate in a single-threaded environment unless explicitly stated otherwise.
Core Requirements
-
Account Management and Fund Transfers
addUser(userId): Creates a new user account.deposit(userId, amount): Adds funds to a specified user's account.transfer(fromUserId, toUserId, amount): Moves funds between two user accounts.- Error Handling: Define and implement appropriate error cases, such as unknown user, insufficient funds, or invalid amounts.
-
Top Spenders Ranking
getTopSpenders(k): Returns the topkaccounts ranked by their total spending.- Definition of Spending: Clearly define "spending" (e.g., total outgoing money via transfers and executed payments).
- Tie-breaking Rules: Specify rules for breaking ties (e.g., by userId).
- Efficiency: Aim for an efficient approach, with data structures like a heap or priority queue being acceptable.
-
Scheduled Payments with Cancellation
schedulePayment(fromUserId, toUserId, amount, executeAtTimestamp): Creates a future payment and returns a uniquepaymentId.cancelPayment(paymentId): Cancels a scheduled payment if it has not yet been executed.- Time Advancement: Provide a mechanism, such as
processPaymentsUpTo(timestamp), to advance the system's time and execute all payments whose scheduled execution time has been reached.
-
User Merging with History Preservation
mergeUsers(sourceUserId, targetUserId): Merges thesourceUserIdaccount into thetargetUserIdaccount.- Post-Merge State: After a merge, the balances are combined, the source user account ceases to exist, and all payment/transfer history must be preserved in a sensible manner. Describe how history is represented and handled after a merge.
- Scheduled Payments Impact: Define how scheduled payments involving the
sourceUserIdare handled after the merge operation.
Design Considerations
Design appropriate data structures and APIs, ensuring correctness for all edge cases.
AI interview prep
Core dilemma
Maintaining data integrity and referential consistency across multiple interconnected in-memory data structures (accounts, transactions, scheduled payments, spending metrics) during complex state changes like user merging, while optimizing for specific query patterns (e.g., top spenders) under single-threaded constraints.
3 tradeoffs and 3 stress tests locked
Interview prep
Unlock the interviewer X-Ray rubric, tradeoff matrix, stress tests, clarifying questions, and key concepts.
Design an in-memory banking system
Design an In-Memory Banking System
Implement an in-memory banking system that supports various operations on user accounts. Assume user IDs are unique strings and monetary amounts are positive integers. The system is initially assumed to operate in a single-threaded environment unless explicitly stated otherwise.
Core Requirements
-
Account Management and Fund Transfers
addUser(userId): Creates a new user account.deposit(userId, amount): Adds funds to a specified user's account.transfer(fromUserId, toUserId, amount): Moves funds between two user accounts.- Error Handling: Define and implement appropriate error cases, such as unknown user, insufficient funds, or invalid amounts.
-
Top Spenders Ranking
getTopSpenders(k): Returns the topkaccounts ranked by their total spending.- Definition of Spending: Clearly define "spending" (e.g., total outgoing money via transfers and executed payments).
- Tie-breaking Rules: Specify rules for breaking ties (e.g., by userId).
- Efficiency: Aim for an efficient approach, with data structures like a heap or priority queue being acceptable.
-
Scheduled Payments with Cancellation
schedulePayment(fromUserId, toUserId, amount, executeAtTimestamp): Creates a future payment and returns a uniquepaymentId.cancelPayment(paymentId): Cancels a scheduled payment if it has not yet been executed.- Time Advancement: Provide a mechanism, such as
processPaymentsUpTo(timestamp), to advance the system's time and execute all payments whose scheduled execution time has been reached.
-
User Merging with History Preservation
mergeUsers(sourceUserId, targetUserId): Merges thesourceUserIdaccount into thetargetUserIdaccount.- Post-Merge State: After a merge, the balances are combined, the source user account ceases to exist, and all payment/transfer history must be preserved in a sensible manner. Describe how history is represented and handled after a merge.
- Scheduled Payments Impact: Define how scheduled payments involving the
sourceUserIdare handled after the merge operation.
Design Considerations
Design appropriate data structures and APIs, ensuring correctness for all edge cases.