Design a Banking Ledger with Accepted Transfers and Account Merges
Quick Overview
Design a banking simulation that separates balances, activity, reserved transfers, and historical state. Make expiration and merge policies explicit while preserving deterministic ranking and retry-safe money movement.
Design a Banking Ledger with Accepted Transfers and Account Merges
Company: Airbnb
Role: Software Engineer
Category: Software Engineering Fundamentals
Difficulty: hard
Interview Round: Online Assessment
Design a banking simulation in four stages: account creation, deposits and payments; activity ranking; transfers that reserve funds until accepted or expired; and account merging with historical balance queries.
### Clarifying Questions
The report does not supply full signatures, output formats, timestamp units, exact expiration equality, or all merge rules. Define these before implementation. For a worked design, use exact integer monetary units, process events in order, expire a transfer at creation time plus24 hours before handling operations at that time, and count only completed money movements as activity. Treat these as practice choices. Explain how account merges affect pending transfers and history rather than assuming a hidden rule.
### Part 1 — Accounts and Basic Operations
Support Create Account, Deposit, and Pay using a balance map.
#### What This Part Should Cover
Validate account identity, amounts, and available funds, and distinguish failed operations from completed transactions.
### Part 2 — Activity Ranking
Rank accounts by total incoming plus outgoing transaction activity, descending, with account ID ascending on ties.
#### What This Part Should Cover
Maintain activity separately from balance and explain which successful operations update it.
### Part 3 — Accepted Transfers
Reserve the source balance when a transfer is created. Complete it only when the target accepts within24 hours; otherwise expire it and return the reserved funds.
#### What This Part Should Cover
A transfer state machine, expiration processing, duplicate acceptance, and boundary ordering.
### Part 4 — Merge and History
Merge account balances and activity, handle pending transfers, and answer balance queries for a specified historical timestamp.
#### What This Part Should Cover
Choose explicit pending-transfer and historical-identity semantics, preserve an audit trail, and avoid using the current balance as a historical answer.
### What a Strong Answer Covers
A consistent ledger and event order across all four stages, exact arithmetic, deterministic ranking, and targeted boundary tests. Missing policies must remain visible as choices rather than invented grader requirements.
### Follow-up Questions
- Why should reserved funds be tracked separately from settled activity?
- How would a backdated event affect the historical balance index?
Overview: Design a banking simulation that separates balances, activity, reserved transfers, and historical state. Make expiration and merge policies explicit while preserving deterministic ranking and retry-safe money movement.
Design a banking simulation in four stages: account creation, deposits and payments; activity ranking; transfers that reserve funds until accepted or expired; and account merging with historical balance queries.
Clarifying Questions Guidance
The report does not supply full signatures, output formats, timestamp units, exact expiration equality, or all merge rules. Define these before implementation. For a worked design, use exact integer monetary units, process events in order, expire a transfer at creation time plus24 hours before handling operations at that time, and count only completed money movements as activity. Treat these as practice choices. Explain how account merges affect pending transfers and history rather than assuming a hidden rule.
Part 1 — Accounts and Basic Operations
Support Create Account, Deposit, and Pay using a balance map.
What This Part Should Cover Guidance
Validate account identity, amounts, and available funds, and distinguish failed operations from completed transactions.
Part 2 — Activity Ranking
Rank accounts by total incoming plus outgoing transaction activity, descending, with account ID ascending on ties.
What This Part Should Cover Guidance
Maintain activity separately from balance and explain which successful operations update it.
Part 3 — Accepted Transfers
Reserve the source balance when a transfer is created. Complete it only when the target accepts within24 hours; otherwise expire it and return the reserved funds.
What This Part Should Cover Guidance
A transfer state machine, expiration processing, duplicate acceptance, and boundary ordering.
Part 4 — Merge and History
Merge account balances and activity, handle pending transfers, and answer balance queries for a specified historical timestamp.
What This Part Should Cover Guidance
Choose explicit pending-transfer and historical-identity semantics, preserve an audit trail, and avoid using the current balance as a historical answer.
What a Strong Answer Covers Guidance
A consistent ledger and event order across all four stages, exact arithmetic, deterministic ranking, and targeted boundary tests. Missing policies must remain visible as choices rather than invented grader requirements.
Follow-up Questions Guidance
Why should reserved funds be tracked separately from settled activity?
How would a backdated event affect the historical balance index?