In-Memory Bank Account System: Create, Deposit, Transfer and Merge Accounts

Implement an in-memory bank account system as a class. The report lists four capabilities: creating accounts, depositing money into an account, transferring money between accounts, and merging two accounts. It also notes a latency issue with transfers. The assessment was taken in C++. ### Constraints and Clarifications - The report gives no method signatures, return values or error rules. State your contract before coding. Reasonable defaults: accounts identified by unique string ids, amounts as positive integers in the smallest currency unit, and failures reported through return values rather than exceptions. - Assume that a failed operation leaves every balance unchanged. ### Clarifying Questions - What should each operation return: a success flag, the new balance, or nothing? - What happens when account creation receives an id that already exists, or another operation names an account that does not exist? - May a transfer overdraw the source account? May an account transfer to itself? - In a merge, which account survives? The report's wording says account `b` is removed. - Does the latency issue refer to the cost of each call as the number of accounts grows, or does a transfer take effect only after a delay? - Besides the balance, is there any other state, such as a transaction history, that a merge must carry over? ### Part 1 — Create accounts and deposit Support creating an account with a zero balance and depositing an amount into an existing account. Choose how the accounts are stored. ```hint Every call starts with a lookup Every later operation begins by finding accounts by id. Work out what that lookup costs in the container you choose, and what removing an account will cost once merging is added. ``` #### What This Part Should Cover - The storage choice and the cost of finding an account by id - Handling of duplicate ids, missing accounts and invalid amounts - An integer type for money, and protection against silent overflow ### Part 2 — Transfer Support transferring an amount from one account to another. The report notes a latency issue with transfers, and its line on account creation mentions a vector. Explain what determines how long a transfer takes in your design, and keep transfers fast as the number of accounts grows. ```hint Validate before you mutate A transfer changes two balances. List every way it can fail, and check all of them before changing either balance. ``` ```hint Count what a transfer touches Count how many accounts a single transfer may examine before it finds the two it needs. ``` #### What This Part Should Cover - Complete validation, so that a failed transfer changes nothing - The cost of a transfer under the chosen storage, and the fix if accounts are found by scanning - Self-transfers, insufficient funds and missing accounts ### Part 3 — Merge accounts Support `merge(a, b)`: account `b`'s balance moves into account `a`, and account `b` is removed, so later operations on `b` fail. ```hint What still points at b List everything in your system that can still refer to `b` after the merge, and decide what each one should do. ``` #### What This Part Should Cover - Validation, including merging an account with itself - Moving the balance and removing the account without invalidating other state - The cost of removal in the chosen container ### What a Strong Answer Covers - An explicit API contract stated before coding: signatures, return values and failure rules - A container chosen for lookup and removal cost, with the complexity of every operation - Validation before mutation in every operation - Integer money with overflow awareness - A test plan covering duplicates, missing accounts, insufficient funds, self-transfer and self-merge ### Follow-up Questions - Calls now arrive from several threads. How do you make transfers and merges atomic without deadlocking when two transfers touch the same accounts in opposite directions? - How would you add a per-account transaction history, and what should a merge do with `b`'s history? - If a transfer must take effect only after a delay and can be canceled until then, how does your data model change, and what happens to pending transfers when one of their accounts is merged?