Design banking with scheduled transfers and merges

Q: Design banking with scheduled transfers and merges

This question evaluates system design and implementation skills for stateful in-memory services, covering temporal event handling, transfer semantics with freezes and expirations, account merges, and historical (time-travel) consistency; it is in the System Design domain and emphasizes practical application with design-level conceptual considerations. Interviews commonly include this problem to assess the ability to model time-dependent state and correctness under out-of-order operations and expirations, reason about data structures, indices and their time/space complexity, and articulate scalability and concurrency trade-offs starting from a single-threaded baseline.

Q: How do I approach System Design interview questions?

System Design questions require understanding of core concepts and practice. PracHub provides solutions with explanations to help you master system design interviews.

Q: What difficulty level is this interview question?

This is a hard difficulty System Design question, commonly asked during Take-home Project rounds at Klaviyo.

Q: What role is this question designed for?

This question is commonly asked for Software Engineer candidates at Klaviyo during technical interviews.

Question

In-Memory Banking System with Scheduled Payments and Account Merges

Design and implement a single-threaded, in-memory banking system that supports scheduled payments, account merges, and time-travel balance queries.

APIs and Semantics

transfer(timestamp, source_account_id, target_account_id, amount) -> str | None

At timestamp, deduct amount from the source account’s available balance and freeze it until the target accepts or the transfer expires exactly 24 hours after initiation. On expiry, funds automatically return to the source and the transfer can no longer be accepted.
If source == target, either account does not exist at timestamp, or the source has insufficient available balance (excluding already frozen funds), return None.
On success, return a unique transfer id like "transfer1", "transfer2".
Frozen funds contribute to both parties’ pending (unsettled) totals and do not enter either account’s transaction history until accepted.

accept_transfer(timestamp, account_id, transfer_id) -> bool

Return True iff the transfer exists, is not expired, not already accepted or cancelled, and account_id is exactly the transfer’s current target at timestamp; otherwise return False.

merge_accounts(timestamp, account_id_1, account_id_2) -> bool

At timestamp, merge account_id_2 into account_id_1. If the IDs are equal or either account does not exist at timestamp, return False.
Cancel all pending transfers originating from account_id_2; also cancel all pending transfers from account_id_1 to account_id_2.
Redirect all other pending inbound transfers whose target is account_id_2 so their target becomes account_id_1.
Increase account_id_1 balance by account_id_2 balance; aggregate both accounts’ historical totals as combined; delete account_id_2; return True.

get_balance(timestamp, account_id, time_at) -> int | None

Return the balance of account_id immediately after processing all operations at time_at. If the account did not yet exist by time_at or had been deleted by then, return None; otherwise return the correct historical balance.

Constraints

Amounts and balances are integers.
Timestamps are integer units; 24 hours is exactly 24 60 60 units after initiation.
Acceptance at or after the expiry moment is invalid.
Operations may arrive in any timestamp order; you must answer historical queries correctly for arbitrary time_at.

Expectations

Describe data structures/algorithms (e.g., hash maps, event log/ledger, min-heap or timer wheel for expirations, indices for per-account state, and any persistence-like strategy for time travel), their time/space complexity, and how to generate unique IDs.
Provide a working single-threaded in-memory implementation and justify design choices.
Briefly discuss how you would extend to handle concurrency and scale.

Minimal Assumptions to Make the Problem Self-Contained

Accounts are created outside the four required APIs (e.g., via a helper create_account(account_id, created_at, initial_balance)). The four required APIs must still enforce existence checks at their timestamps.
"Balance" means settled ledger balance (excludes frozen funds). "Available" means balance minus currently frozen outgoing amounts.
Event ordering at the same timestamp will be deterministic: Initiations first, then Merges, then Accepts, then Expirations.

Design banking with scheduled transfers and merges

Quick Overview

In-Memory Banking System with Scheduled Payments and Account Merges

APIs and Semantics

Constraints

Expectations

Minimal Assumptions to Make the Problem Self-Contained

Solution

Comments (0)