Design a peer-to-peer money-transfer product. Users can hold an account, send money to another user, view transfer history, and see an accurate balance. A prototype may keep data in memory, but your production design must preserve money safely across crashes, retries, and concurrent requests. Cover APIs, data model, transfer state machine, balance accounting, idempotency, concurrency, failure recovery, and the differences between an in-memory demonstration and a production service. ### Constraints & Assumptions - All transfers use one currency in the initial version. - A transfer cannot create or destroy money. - Clients and internal workers may retry after timeouts. - Two transfers from the same sender can arrive concurrently. - External bank settlement is out of scope, but the model should leave room for asynchronous funding later. ### Clarifying Questions to Ask - Are transfers immediate, cancelable, or subject to review? - May users spend pending incoming funds? - What balance types are required: available, pending, and total? - What limits, identity checks, and audit retention are expected? ### What a Strong Answer Covers - Uses immutable ledger entries and derives or transactionally maintains balances. - Defines idempotent transfer creation and a legal state-transition model. - Prevents double spending with a clear concurrency strategy. - Explains atomicity between debit and credit and recovery from partial work. - Treats in-memory storage as a replaceable prototype boundary, not production durability. - Includes authorization, abuse controls, reconciliation, monitoring, and auditability. ### Follow-up Questions 1. How would you add asynchronous bank funding without exposing unsettled money as available? 2. How would you reconcile a materialized balance against the ledger? 3. What changes are needed for multiple currencies and exchange rates?