##### Question Design and implement a two-phase ("pull-style") money-transfer system in which funds are first **held** on the source account and then either captured or released. The transfer is created by the source; the target decides whether to **accept** it; either party may **cancel** while it is still pending. Implement the following operations: 1. `String transfer(long timestamp, String targetAccountId, int amount)` — create a transfer, place a **hold** on the source account's funds, and return a unique `transferId`. 2. `boolean accept(long timestamp, String accountId, String transferId)` — finalize the transfer: move the held funds from the source to the target (`accountId` must be the target). 3. `boolean cancel(long timestamp, String accountId, String transferId)` — release the hold and fully restore the source account's availability. In your design and write-up, address: - **Balance semantics:** clearly distinguish the **ledger (posted) balance** from the **available balance**, and show how a hold affects each on the source and target accounts. - **State machine:** define the legal transfer states (e.g. `PENDING → ACCEPTED | CANCELED`, plus an optional `EXPIRED`) and the allowed transitions; terminal states are final. - **Data structures:** maintain `allTransfers` and `pendingTransfers` in **hash maps (not lists)** so that lookups and state changes are O(1). Track per-account hold totals incrementally instead of scanning lists. - **Authorization:** only the target may `accept`; the source or the target may `cancel` while pending. - **Idempotency & duplicate requests:** define behavior for repeated `accept`/`cancel`, for an optional client idempotency key on `transfer`, and for an unknown/invalid `transferId`. - **Atomicity & concurrency:** how balance, hold, and transfer-state updates are made atomic (per-account locks, deterministic lock ordering to avoid deadlock). - **Expiration (TTL):** optional hold expiry using `timestamp` — how an expired pending transfer is auto-released and how `accept`/`cancel` behave against it. - **Failure recovery & durability:** how to keep the system consistent across crashes (ACID transaction, WAL/outbox, background reconciler/sweeper). - **Error handling:** invalid `transferId`, wrong actor, insufficient funds, non-positive amount, self-transfer. - **Complexity:** give the time and space complexity of each operation.

This interview question evaluates requirements, scale assumptions, API/data design, architecture, trade-offs, failure modes, and rollout in a realistic interview setting. A strong answer for Implement held transfers with accept/cancel states assumptions, handles edge cases, explains trade-offs, and shows how to validate the result clearly.

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.

What difficulty level is this interview question?

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

What role is this question designed for?

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

Implement held transfers with accept/cancel

Design and implement a two-phase ("pull-style") money-transfer system in which funds are first held on the source account and then either captured or released. The transfer is created by the source; the target decides whether to accept it; either party may cancel while it is still pending.

Implement the following operations:

String transfer(long timestamp, String targetAccountId, int amount) — create a transfer, place a hold on the source account's funds, and return a unique transferId .
boolean accept(long timestamp, String accountId, String transferId) — finalize the transfer: move the held funds from the source to the target ( accountId must be the target).
boolean cancel(long timestamp, String accountId, String transferId) — release the hold and fully restore the source account's availability.

In your design and write-up, address:

Balance semantics: clearly distinguish the ledger (posted) balance from the available balance , and show how a hold affects each on the source and target accounts.
State machine: define the legal transfer states (e.g. PENDING → ACCEPTED | CANCELED , plus an optional EXPIRED ) and the allowed transitions; terminal states are final.
Data structures: maintain allTransfers and pendingTransfers in hash maps (not lists) so that lookups and state changes are O(1). Track per-account hold totals incrementally instead of scanning lists.
Authorization: only the target may accept ; the source or the target may cancel while pending.
Idempotency & duplicate requests: define behavior for repeated accept / cancel , for an optional client idempotency key on transfer , and for an unknown/invalid transferId .
Atomicity & concurrency: how balance, hold, and transfer-state updates are made atomic (per-account locks, deterministic lock ordering to avoid deadlock).
Expiration (TTL): optional hold expiry using timestamp — how an expired pending transfer is auto-released and how accept / cancel behave against it.
Failure recovery & durability: how to keep the system consistent across crashes (ACID transaction, WAL/outbox, background reconciler/sweeper).
Error handling: invalid transferId , wrong actor, insufficient funds, non-positive amount, self-transfer.
Complexity: give the time and space complexity of each operation.

Constraints & Assumptions

Preserve the scope, facts, inputs, and requested outputs from the prompt above.
If the prompt leaves a detail unspecified, state a reasonable assumption before relying on it.
Keep the answer interview-ready: concise enough to present, but concrete enough to implement or evaluate.

Clarifying Questions to Ask Guidance

Clarify users, core use cases, read/write patterns, scale, latency, availability, and data retention.
State explicit assumptions before making sizing or architecture decisions.
Prioritize the functional path first, then address reliability, security, observability, and rollout.

What a Strong Answer Covers Guidance

A scoped requirements summary with concrete non-goals and success metrics.
API, data model, architecture, consistency, capacity, and operations.
Reasoned trade-offs among simple and scalable designs, including bottlenecks and failure modes.
A validation, monitoring, migration, and launch plan appropriate for the risk level.

Follow-up Questions Guidance

What breaks first at 10x traffic or data volume?
How would you degrade gracefully during dependency failures?
What metrics and alerts would prove the design is healthy after launch?