Bank ledger with two-step transfers and merges

The spec used here (timestamps are milliseconds and only grow; failed calls return None or False):

Clarify first. Is the hold visible in the sender's balance (yes: the balance drops at transfer time)? Can you transfer to yourself (no)? Does an expired transfer refund at the moment of expiry, even if nobody calls anything (we only need the observable result to be right, so we settle lazily at the next call)? What if the sender was merged before the transfer expires (the refund goes to the account that absorbed it)?

The key decision: separate an account's identity from its id string. The Level 3 trap is "merge, then recreate the id". If transfers store the string "bob", the new "bob" can accept money meant for the old one. Store a reference to an Account object instead. Each create_account makes a new object, so a recreated id is a different account by construction. A merge then repoints the pending transfers that referenced the gone object.

Lazy expiry. Keep a min-heap of (expires_at, transfer_id). Every public method first calls _settle(ts), which pops due transfers that are still pending and refunds them. Because timestamps only grow, settling before each call gives the same answers as a real timer. Entries for transfers that were already accepted are skipped when popped.

Invariant (worth stating, and testing). Total money = sum of balances + sum of pending holds. Deposits add to it, withdrawals subtract, and nothing else changes it: not transfers, accepts, refunds or merges.

import heapq
from itertools import count

DAY_MS = 86_400_000


class Account:
    def __init__(self, account_id):
        self.id = account_id
        self.balance = 0


class Transfer:
    def __init__(self, src, dst, amount, expires_at):
        self.src, self.dst, self.amount, self.expires_at = src, dst, amount, expires_at
        self.status = "pending"  # pending | accepted | expired | cancelled


class Bank:
    def __init__(self):
        self.accounts = {}      # id -> Account (live accounts only)
        self.transfers = {}     # transfer id -> Transfer
        self.expiry = []        # heap of (expires_at, seq, transfer id)
        self._seq = count(1)

    # -- helpers -----------------------------------------------------------
    def _settle(self, ts):
        while self.expiry and self.expiry[0][0] <= ts:
            _, _, tid = heapq.heappop(self.expiry)
            t = self.transfers[tid]
            if t.status == "pending":
                t.status = "expired"
                t.src.balance += t.amount

    def _live(self, account_id):
        return self.accounts.get(account_id)

    # -- level 1 -----------------------------------------------------------
    def create_account(self, ts, account_id):
        self._settle(ts)
        if account_id in self.accounts:
            return False
        self.accounts[account_id] = Account(account_id)
        return True

    def deposit(self, ts, account_id, amount):
        self._settle(ts)
        acct = self._live(account_id)
        if acct is None or amount <= 0:
            return None
        acct.balance += amount
        return acct.balance

    def withdraw(self, ts, account_id, amount):
        self._settle(ts)
        acct = self._live(account_id)
        if acct is None or amount <= 0 or acct.balance < amount:
            return None
        acct.balance -= amount
        return acct.balance

    # -- level 2 -----------------------------------------------------------
    def transfer(self, ts, src_id, dst_id, amount):
        self._settle(ts)
        src, dst = self._live(src_id), self._live(dst_id)
        if src is None or dst is None or src is dst or amount <= 0 or src.balance < amount:
            return None
        src.balance -= amount  # hold
        seq = next(self._seq)
        tid = f"transfer{seq}"
        self.transfers[tid] = Transfer(src, dst, amount, ts + DAY_MS)
        heapq.heappush(self.expiry, (ts + DAY_MS, seq, tid))
        return tid

    def accept_transfer(self, ts, account_id, transfer_id):
        self._settle(ts)
        t = self.transfers.get(transfer_id)
        acct = self._live(account_id)
        if t is None or acct is None or t.status != "pending" or t.dst is not acct:
            return False
        t.status = "accepted"
        acct.balance += t.amount
        return True

    # -- level 3 -----------------------------------------------------------
    def merge_accounts(self, ts, keep_id, gone_id):
        self._settle(ts)
        keep, gone = self._live(keep_id), self._live(gone_id)
        if keep is None or gone is None or keep is gone:
            return False
        keep.balance += gone.balance
        for t in self.transfers.values():
            if t.status != "pending":
                continue
            ends = {t.src, t.dst}
            if ends == {keep, gone}:
                t.status = "cancelled"
                keep.balance += t.amount  # the refund lands in keep whichever side sent it
                continue
            if t.src is gone:
                t.src = keep
            if t.dst is gone:
                t.dst = keep
        del self.accounts[gone_id]
        return True

In the cancelled case the refund goes straight to keep: whether keep or gone sent it, both are now the same account, and gone's balance was already folded in, so refunding to gone would lose the money.

Space is O(A + T): accounts, transfers and heap entries.

1. Historical balances. Record (ts, balance) on every change through one _set_balance helper, then binary-search for "balance at time t". Keep the history on the Account object so a recreated id starts a new history rather than continuing the old one.
2. Pending index. The merge scan is O(all transfers). Keep account.pending: set[transfer id] updated on transfer, accept, expiry and cancel, and merge in O(pending of the gone account).
3. Real ledgers. Replace mutable balances with append-only double-entry postings: a hold is a posting from the account to a "holds" account, accept moves it from holds to the recipient, expiry moves it back. Balances are sums. The money invariant becomes "every entry has a matching opposite entry", which auditors can check.
4. Concurrency. Lock both accounts in a fixed order (by internal uid) for transfers and merges to avoid deadlock. Expiry run by a background worker needs the same locks and an idempotent status change (pending -> expired only if still pending).
5. Idempotency. Network retries can send transfer twice. Accept a client-supplied idempotency key and return the original transfer id on a repeat.

Mid-level (L4)

• Gets Level 1 and the hold/accept flow right, including "only the recipient can accept" and "accept once".
• Implements expiry with the correct boundary (expired at exactly 24 hours).
• Tests the failure cases (unknown account, insufficient funds, self-transfer).

Senior (L5)

• Settles expiry lazily with a heap and explains why it matches a real timer when timestamps grow.
• Separates account identity from the id string, so a recreated id cannot take the old account's transfers.
• Handles all merge cases: incoming, outgoing, and a pending transfer between the two accounts.

Staff (L6+)

• States the conservation invariant and uses it to check every operation.
• Moves toward double-entry postings, idempotency keys and lock ordering without being asked, while keeping the timed solution simple.
• Leaves the code structured so a fourth level (history, fees, scheduled payments) is an addition, not a rewrite.