Implement an in-memory banking service whose operations arrive in nondecreasing timestamp order.
Question
Implement an in-memory banking service whose operations arrive in nondecreasing timestamp order.
```python
class Bank:
def create_account(self, timestamp: int, account_id: str) -> bool: ...
def deposit(self, timestamp: int, account_id: str, amount: int) -> int | None: ...
def withdraw(self, timestamp: int, account_id: str, amount: int) -> int | None: ...
def transfer(self, timestamp: int, source: str, destination: str, amount: int) -> str | None: ...
def transfer_accept(self, timestamp: int, transfer_id: str) -> bool: ...
def merge_account(self, timestamp: int, source: str, destination: str) -> bool: ...
```
## Requirements
- Account creation starts at zero and returns `True`, or `False` if that identifier is already active. Deposits and withdrawals return the total balance, including held funds; invalid accounts or invalid amounts return `None`. A zero deposit is a read of the current balance. Negative deposits, and zero or negative withdrawals and transfers, are invalid.
- Starting a transfer requires both accounts to exist and available funds (total balance minus holds) to cover the amount. It reserves funds immediately without changing the total balance and returns `tx1`, `tx2`, and so on for successful transfers only. Invalid transfers return `None` and do not consume an identifier.
- Acceptance returns `True` only when it completes a pending transfer exactly once, subtracting source balance and hold and adding destination balance. Otherwise it returns `False`. Each hold expires at creation timestamp plus 1,000; expiration is processed before every operation, including invalid operations. At the exact expiry timestamp acceptance fails and the reservation is released without changing total balance.
- Merge returns `True` only for two distinct existing accounts. It moves source balance and holds into the destination, redirects every pending transfer endpoint referencing the source, then removes the source account. Otherwise it returns `False`. A previously pending transfer may consequently have both endpoints at the destination; accepting it releases its hold without changing the destination total balance.
- A merged account identifier may later be recreated as a new account without inheriting old state.
- Reject self-transfers and withdrawals exceeding available funds. Apart from ordinary hold expiration at the operation timestamp, rejected operations do not mutate balances, accounts, transfer status or the identifier counter.
All timestamps are nonnegative integers and arrive in nondecreasing order, including equal timestamps. Amounts are integers. Use integer arithmetic, with no overdraft or currency conversion. Each independent command sequence begins with a new Bank instance. A sequence is a `calls` list whose entries contain one of the six method names followed by the positional arguments declared above; return the list of method results in input order.
## Suggested implementation approach
These milestones organize the complete requirements above, rather than adding separately assessed behavior.
1. Implement account creation, deposit, and withdrawal.
2. Add held transfers, acceptance, and lazy expiry.
3. Add account merge and identity recreation.
## Design discussion
Propose separately specified interfaces for balance-at-time and transaction-history queries. Discuss concurrency, idempotency keys, durable storage and double-entry accounting. These are design extensions, not required methods in the six-method interface.The public brief is identical for people and crawlers. Account access changes tools, not the indexed description.