## Interview Prompt Implement an in-memory cloud credit system with strictly increasing operation timestamps. It creates workspaces, tops up and transfers credits, ranks consumers by outgoing credits, records compute consumption, pays a floor-rounded 2% rebate exactly 86,400,000 milliseconds later, reports charge status, merges workspaces, and answers historical balance queries. A merge preserves balances, outgoing totals, charges, pending rebates, and each workspace's pre-merge history. ### Constraints & Assumptions - Every public operation processes all rebates due at or before its timestamp first. - Successful consumptions receive globally sequential charge IDs; failed attempts do not. - Outgoing totals include transfers and consumption but never top-ups, incoming funds, or rebates. - After B merges into A, B is inactive, but B's balance before the merge remains queryable. - A's historical balance before the merge must not include B retroactively. ### Clarifying Questions to Ask - Does a zero-value rebate still transition its charge to received? - How are simultaneous due rebates ordered when timestamps are otherwise unique? - Should historical queries include internally processed rebates as balance-changing events? ### What a Strong Answer Covers - A canonical workspace/account model plus immutable charge ownership history. - A due-rebate heap and one processing boundary shared by every operation. - Correct merge redirection for pending rebates and charge lookup without rewriting history. - Append-only per-workspace balance timelines queried by predecessor search. - Precise existence intervals so removed workspaces remain queryable only before merge time. ### Follow-up Questions - How would you support undoing a mistaken merge without rewriting history? - What data structure keeps top-consumer queries fast under frequent updates? - How would idempotency work if operation timestamps were not unique?