Account Balance Manager Part 3 - Platform Coverage

Practice sequence

1. Part 1: Calculate Totals
2. Part 2: Reject Overdrafts
3. Part 3: Platform Coverage (you are here)

Reported transaction format

The linked interview report uses account_name,timestamp,currency,amount rows. Its examples are chronological and use one currency. Positive amounts add money and negative amounts withdraw money.

Practice contract

For this exercise, assume transactions arrive in order as account_id,amount strings, every account starts with a balance of 0, and one identifier names the platform account.

• Apply a transaction normally when the resulting balance is non-negative.
• When a non-platform account would become negative, the platform covers exactly the shortfall so that account ends at 0.
• The platform account's own transactions are never covered, and sufficient platform funding is available.

Return the total amount covered by the platform.

The runner projects each chronological, single-currency source row to account_id,amount. Timestamps and currency are omitted; do not infer sorting or currency-conversion behavior. The existing callable return format defines the judged task.

Interview follow-up: Report Part 3a state

The source additionally asks for max_reserve, rejected transactions, and final nonzero balances. The report does not define repayment, reserve evolution, or insufficient-funds behavior. For this practice follow-up, assume no repayment and sufficient platform funding, and define reserve as cumulative funds committed to coverage. It never decreases, so its maximum equals the judged total coverage.

Keep the final account ledger, emit its nonzero balances, and report an empty rejection list under these practice rules: user shortfalls are covered and platform-own signed changes apply directly. These are the follow-up outputs; the judged method still returns one integer.

account_name,timestamp,currency,amount
acct_123,1,usd,1000
acct_321,3,usd,400
acct_321,4,usd,-500

With platform acct_123, the shortfall is 100. The judged return is 100; the fuller outputs are max_reserve = 100, rejected_transaction = [], and acct_123:900. The covered account ends at zero and is omitted. The malformed account label in the report is resolved from its input. The mentioned Part 3b was not read by the author and supplies no rule.

Complete report exercise

As an additional practice exercise, implement fullCoverageReport with a String[] transactions parameter and a String platformAccount parameter. Input rows have exactly four comma-separated fields account_name,timestamp,currency,amount, no header, one currency, and chronological order; the account and numeric bounds above apply. Return a String[][] with exactly three rows: row 0 is a singleton containing the decimal max_reserve; row 1 contains rejected original rows; row 2 contains final nonzero account:balance strings in ASCII lexicographic account order. This serialization is authored for practice. The workspace judges only processWithCoverage on its two-field input and integer return.

For this follow-up, assume no repayments and sufficient platform funds whenever coverage is needed. Reserve is the cumulative amount committed to coverage, so it never decreases and its maximum equals total coverage. Platform-own signed changes apply directly without coverage. Under those explicit rules every transaction is accepted, so row 1 is empty. These rules fill source gaps; they are not additional recovered interview facts.

The source example returns [["100"],[],["acct_123:900"]]: 1000 platform funding minus the recipient’s 100 shortfall leaves 900; the recipient is zero and omitted. The malformed source account label is corrected using the inputs.

A second practice example uses platform p and rows ["p,1,usd,100", "u,2,usd,-10", "u,3,usd,4", "u,4,usd,-7", "v,5,usd,3"]. The two coverages are 10 and 3. The deposit of 4 belongs to u and does not repay earlier coverage; it reduces the next shortfall from 7 to 3. Return [["13"],[],["p:87","v:3"]]. The canonical judged projection returns 13. No Part 3b behavior is inferred.