Design a Ledger with Separate Acceptance, Limit, and Settlement States

Implement `process_ledger(commands)` for a financial-account ledger that receives deposits. The function processes the commands strictly in the given order. There are three kinds of command: initialize an account, submit a deposit into an account, and query an account's balance. It returns one string that contains every query result, in command order, joined by commas. Each deposit uses a deposit method. Methods differ in three ways: how long the funds take to settle, a cutoff time that decides which settlement window a request falls into, and the amount limits that apply. The core difficulty is that three moments can differ: when a deposit request is accepted, when it starts to count against a limit, and when its funds appear in the balance. ### Constraints and Clarifications - Assume every command carries a timestamp and that commands arrive in nondecreasing timestamp order. The ledger's current time is the timestamp of the command being processed. - Amounts are money and must be computed exactly. - The command syntax, and each method's settlement delay, cutoff, and limit values, are inputs to your design. Write the ones you use as an explicit policy table, not as real banking rules. ### Clarifying Questions - Does a deposit timestamped exactly at the cutoff fall in the current settlement window or the next? - Is a limit per request, per account per day, or per method, and does an accepted but unsettled deposit count against it? - Does a balance query report only settled funds, or settled and pending funds separately? - What should the output contain for a rejected deposit, a command for an account that does not exist, or a repeated initialization? ### Part 1 — Commands, Account State, and Output Define the account state and the main processing loop for initialization, deposit, and balance-query commands. Include how query results are collected and formatted into the final string. ```hint Decide what a query reads Settled funds and accepted-but-unsettled funds answer different questions. Decide which one a query reports before you write the loop. ``` #### What This Part Should Cover - How accounts are identified, and the errors initialization can raise. - An exact representation for amounts. - What each accepted deposit records. - The output format of the result string. ### Part 2 — Settlement Timing and Cutoffs Each deposit method has a settlement delay and a cutoff time. Explain how the ledger computes when an accepted deposit settles, and how settled funds become visible to later queries as time moves forward. ```hint Catch the clock up first Before handling any command, consider what should already have happened between the previous command's timestamp and this one. ``` #### What This Part Should Cover - The rule for a deposit at the cutoff boundary, and how the settlement time is computed. - How pending settlements are scheduled and applied. - The ordering rule when a settlement and a command share a timestamp. ### Part 3 — Amount Limits Each deposit method also has amount limits. Explain when a deposit is checked against a limit, when it starts to consume limit capacity, and when that capacity resets or is released. ```hint Pick the moment of occupation Counting a deposit against the limit when it is accepted and counting it when it settles give different answers whenever several deposits are pending. ``` #### What This Part Should Cover - The difference between per-request and aggregate limits. - Whether capacity is consumed at acceptance or at settlement. - How the limit window resets. - Why a rejected deposit must leave all state unchanged. ### What a Strong Answer Covers - A deposit lifecycle that keeps accepted, pending, settled, and rejected distinct. - Time-ordered processing driven by an explicit per-method policy table, with exact arithmetic. - The complexity of the processing loop, and tests at every cutoff, settlement, and limit boundary. ### Follow-up Questions - What does a query return when it shares a timestamp with a settlement? - How would the design change if commands could arrive out of timestamp order? - If a pending deposit fails or is cancelled, what happens to the limit capacity it holds? - How would you add a new deposit method without changing the processing loop?