Single-Process BankSystem: APIs, Data Model, Algorithms, and Edge Cases

Context and Assumptions

You are asked to design and implement a single-process banking system with monotonically increasing integer timestamps and non-negative integer amounts. For levels 1–3, assume one account per customer such that accountId == customerId. Transfers place an immediate hold on the source account and have a fixed expiry window.

Note: The original transfer signature did not include the source account. To make the API unambiguous, we normalize it to transfer(timestamp, sourceAccountId, targetAccountId, amount).

Assume a fixed expiry window W (in timestamp units), configured at system initialization.

APIs to Support

1. bool createAccount(timestamp, customerId)
2. int deposit(timestamp, customerId, amount)
3. int pay(timestamp, sourceAccountId, targetAccountId, amount)
4. String transfer(timestamp, sourceAccountId, targetAccountId, amount)
   • Returns a unique transferId and immediately places a hold (deducts funds) on the source account.
5. boolean accept(timestamp, accountId, transferId)
6. void mergeCustomers(oldId, newId)

Requirements

(a) For levels 1–3, one account per customer (accountId == customerId). A transfer places a hold and deducts from the source at transfer time. An accept within the expiry window completes the transfer by crediting the target. If a transfer expires before acceptance, held funds are returned to the source.

(b) All balance-mutating operations (deposit and pay) must first detect and unwind any expired transfers affecting the involved accounts so return values reflect correct post-expiration balances.

(c) On successful acceptance, the transfer amount contributes to the target account’s activity metric (used by a Top‑N query). Expired transfers do not contribute.

(d) Define precise return values and error behavior for: nonexistent accounts, insufficient funds, duplicate or late accepts, invalid/expired transferIds, and idempotency expectations.

(e) mergeCustomers(oldId, newId) merges customer identities while preserving each original account’s balance and full transaction history; reassign all of oldId’s accounts and any open/held/settled transfers to newId without altering historical records. Also explain chosen data structures, time/space complexity for each API, and how to test long mixed operation sequences with many accounts.