# Extend a Banking Interface with Scheduled Payments and Account Merges You maintain an in-memory banking service whose public interface already supports creating accounts and recording balance-changing transactions. Extend the interface without exposing internal storage details. Assume every request carries a unique request ID and a logical integer timestamp. Requests are processed in increasing timestamp order. Monetary values are non-negative integer cents, and an operation that would overdraw an account must fail without changing state. At each timestamp, process scheduled payments due at that time before processing an explicitly submitted operation with that timestamp. Process multiple due payments in their creation order. A scheduled payment that lacks sufficient funds at execution time fails permanently without changing the balance. ### Clarifying Questions to Ask - How will creation order be represented so equal-time payments execute deterministically? - What should happen to pending payments when either account is merged? - Must old account IDs remain queryable after a merge? - Which failures must be idempotent when a request is retried? ### Part 1: Scheduled Payments Design interface methods to schedule a payment that debits a specified amount from one account at a future timestamp, cancel a pending payment, and process payments when their execution time arrives. Define identifiers, validation, ordering, insufficient-funds behavior, and retry semantics. #### What This Part Should Cover - A precise API contract and explicit state transitions - Stable ordering for payments due at the same time - Idempotent request handling and safe cancellation races - Efficient discovery of due payments without scanning every account ### Part 2: Account Merges Design a merge operation that combines two accounts while preserving the surviving account's history and correctly reconciling balances and pending scheduled payments. Explain how subsequent requests using the retired account ID behave. #### What This Part Should Cover - Atomicity and invariants for balances and account identity - A documented policy for pending payments owned by the retired account - Historical lookup and alias or tombstone behavior - Concurrency control for merges racing with other operations ### What a Strong Answer Covers - Clear separation between the public interface, domain state, and scheduling mechanism - Deterministic ordering, idempotency, and failure semantics - Atomic transitions that never create or destroy money accidentally - Tests for boundary timestamps, retries, insufficient funds, cancellation, and merge races ### Follow-up Questions - How would the design change if requests can arrive out of timestamp order? - How would you persist the state and recover scheduled work after a crash? - What information would you retain for an auditable transaction history? - How would you prevent two workers from executing the same payment?