This interview question evaluates requirements, scale assumptions, API/data design, architecture, trade-offs, failure modes, and rollout in a realistic interview setting. A strong answer for Schedule and execute future payments states assumptions, handles edge cases, explains trade-offs, and shows how to validate the result clearly.
##### Question
Design a feature to schedule payments at future timestamps. The system must execute the payment exactly at the scheduled time, update the involved account balances, and skip execution if the source balance is insufficient.
Quick Answer: This interview question evaluates requirements, scale assumptions, API/data design, architecture, trade-offs, failure modes, and rollout in a realistic interview setting. A strong answer for Schedule and execute future payments states assumptions, handles edge cases, explains trade-offs, and shows how to validate the result clearly.
You are building a balance-transfer service (e.g., an internal wallet). Users can schedule a payment to move funds from a source account to a destination account at a future timestamp.
Requirements
Design a feature that supports the following:
A user can schedule a payment at a future UTC timestamp.
The system executes the payment at the scheduled time.
On execution, the system updates the involved account balances atomically.
If the source balance is insufficient at execution time, the payment is skipped (no balance changes).
Assumptions (minimal to make the problem well-scoped)
Single region deployment; relational database available.
Timestamps are stored and compared in UTC with second-level precision.
Payments are in a single currency (multi-currency handling is out of scope).
“Execute at the scheduled time” means trigger at or immediately after the timestamp (sub-second jitter is acceptable in distributed systems).
What to Deliver
Provide a design that covers:
High-level architecture and components.
Data model and key constraints.
Execution flow (scheduling and run-time) and concurrency control.
Handling of insufficient funds, idempotency, and failure/retry.
Brief API sketch and operational considerations (monitoring, background jobs).
Constraints & Assumptions
Preserve the scope, facts, inputs, and requested outputs from the prompt above.
If the prompt leaves a detail unspecified, state a reasonable assumption before relying on it.
Keep the answer interview-ready: concise enough to present, but concrete enough to implement or evaluate.
Clarifying Questions to Ask Guidance
Clarify users, core use cases, read/write patterns, scale, latency, availability, and data retention.
State explicit assumptions before making sizing or architecture decisions.
Prioritize the functional path first, then address reliability, security, observability, and rollout.
What a Strong Answer Covers Guidance
A scoped requirements summary with concrete non-goals and success metrics.
API, data model, architecture, consistency, capacity, and operations.
Reasoned trade-offs among simple and scalable designs, including bottlenecks and failure modes.
A validation, monitoring, migration, and launch plan appropriate for the risk level.
Follow-up Questions Guidance
What breaks first at 10x traffic or data volume?
How would you degrade gracefully during dependency failures?
What metrics and alerts would prove the design is healthy after launch?