In-Memory Workspace Credit System With Transfers, Top-K and Scheduled Transfers

Implement an in-memory system that manages workspaces. Each workspace has a unique ID and a credit balance. The exercise is a timed, level-based coding assessment: every level adds operations to the same class, every operation is called with a timestamp, and automated tests check the results. The assessment had four levels in 90 minutes; the three reported levels are below. ### Constraints and Clarifications - Method names, argument order and return values were not reported. Define a small interface, state it, and keep it stable as levels are added, because calls from earlier levels must keep working. - Every operation receives the current timestamp as an integer. - Tests check exact results. A simple implementation is acceptable as long as it is correct. ### Clarifying Questions - What should an operation return when it cannot be performed, for example creating an ID that already exists or referring to a workspace that does not exist? - Can a balance go negative, and is a transfer from a workspace to itself allowed? - Do timestamps strictly increase from one call to the next? ### Part 1 — Workspaces, credit and instant transfers Support three operations: create a workspace with a given ID, add credit to an existing workspace, and transfer credit from one workspace to another with immediate effect. ```hint Check everything before changing anything A transfer touches two balances and can fail for several reasons. Settle all of them before either balance changes. ``` #### What This Part Should Cover - A data model keyed by workspace ID - Validation of duplicate or unknown IDs, non-positive amounts and insufficient credit, with consistent return values - Transfers that never change one balance without the other ### Part 2 — Top K workspaces Add an operation that returns the top K workspaces. ```hint Pin down the order first Write down the exact ranking key and tie-break before choosing between a sort and a heap, and check which end your language's heap or comparator actually puts first. ``` #### Clarifying Questions for this Part - What are workspaces ranked by: current credit, or a cumulative figure such as total credit sent? - How are ties broken, and is the output a list of IDs or of IDs with their values? - What is returned when K exceeds the number of workspaces? #### What This Part Should Cover - A total order with an explicit tie-break, so the output is deterministic - A justified choice between sorting all workspaces and keeping a bounded heap - K of zero, and K larger than the number of workspaces ### Part 3 — Scheduled and cancellable transfers Add an operation that schedules a transfer to happen at a future time, and an operation that cancels a scheduled transfer that has not happened yet. Every operation, including read-only ones such as top K, must see the effects of all scheduled transfers that have come due by its timestamp, applied in the order in which they came due. ```hint Pending work in time order Keep scheduled transfers in a structure ordered by due time, and decide whether a cancelled transfer is removed at once or skipped later. ``` ```hint Catch up before acting Each public operation needs the system brought up to date with its own timestamp first. Find a way to guarantee that without duplicating the logic in every method. ``` #### Clarifying Questions for this Part - Is the execution time given as an absolute timestamp or as a delay after the scheduling call? - What does scheduling return so that a later call can cancel the transfer, and who is allowed to cancel it? - Is credit checked when the transfer is scheduled, when it executes, or both? What happens to a due transfer whose source no longer has enough credit? - Does a transfer due exactly at an operation's timestamp take effect before that operation? Which of two transfers due at the same time runs first? #### What This Part Should Cover - A pending-transfer structure ordered by due time, with a deterministic tie-break - Catch-up processing before every operation, including reads - Cancelling unknown, already executed, already cancelled, or another workspace's transfers - What happens when a due transfer cannot be applied ### What a Strong Answer Covers - An interface defined up front and kept stable across levels - Deterministic results everywhere, including ranking ties and transfers due at the same time - No partially applied transfer on any failure path - A structure that absorbs each new level with small, local changes - Time management that reaches the later levels within the limit ### Follow-up Questions - How would you merge one workspace into another, and what happens to scheduled transfers that reference the merged-away ID? - How would you answer "what was this workspace's balance at time t" for any past t, and what would you need to record from the very first operation to make that cheap? - If top K is called far more often than balances change, how would you keep it fast? - What breaks if operations can arrive with timestamps out of order, and how would you handle it?