Scheduled Payments Extension — Chronological Execution, Maps-Based Pending Store, and Top-N Spenders
Context
You are extending an existing in-memory payment system that already supports immediate transfers between accounts and maintains a "Top-N spenders" feature. Add support for scheduled payments that execute after a delay and must run in chronological order. Operations must be efficient for lookup/cancellation and correct under concurrent execution.
Assume the system tracks accounts by ID, balances as integers (smallest currency unit), and has an existing immediate transfer function that updates balances and the Top-N spenders aggregator.
New APIs to Implement
-
String schedulePayment(long timestamp, String sourceAccountId, String targetAccountId, int amount, long delay)
-
Returns a unique scheduleId for the scheduled payment.
-
The payment should be scheduled to execute at executeAt = timestamp + delay.
-
boolean cancelScheduledPayment(long timestamp, String accountId, String scheduleId)
-
Cancels a previously scheduled payment if it is still pending.
-
Returns true only if this call transitions the payment from pending to canceled; false otherwise (idempotent).
-
Add a runner entry point to execute due items and return the execution summary string in chronological order:
-
String processDuePayments(long now)
-
Executes all pending payments with executeAt <= now, in chronological order. The return value is a concatenation of "{accountId}{amount}" for each successful execution in the order they were applied.
Requirements
-
Execution order:
-
Strictly ascending by executeAt.
-
For ties (same executeAt), break ties deterministically (e.g., by schedule time, then scheduleId lexicographically).
-
Data structures:
-
Use maps (not lists) to manage pending items for efficient O(1) lookup/cancel.
-
You may use ordered map variants (e.g., a tree/navigable map) to maintain chronological execution.
-
Funds reservation:
-
Explicitly state whether funds are reserved at schedule time or at execution time, and describe implications.
-
Failures/insufficient funds:
-
Define behavior when the source account has insufficient funds at execution (e.g., skip and mark failed, no retries), and how it impacts the summary string.
-
Cancel idempotency:
-
Define precise return semantics for repeated cancels, cancel-after-execution, and cancel of unknown IDs.
-
Top-N spenders:
-
Specify exactly when and how scheduled payment executions update the existing Top-N spenders feature.
-
Concurrency and idempotency:
-
Ensure a payment executes at most once; cancels and executions must be race-safe.
Output/Logging
-
When processDuePayments(now) executes due payments, return a string summarizing the successful executions by concatenating "{sourceAccountId}{amount}" in the exact execution order.
-
You may omit failed or canceled items from the summary.
Deliverables
-
Describe the in-memory data model and algorithms used to:
-
Schedule, cancel, and execute payments.
-
Maintain chronological order using maps.
-
Handle failures and idempotency.
-
Update Top-N spenders.
-
Provide a small illustrative example demonstrating the execution order and summary.