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 Implement account CRUD and transfer states assumptions, handles edge cases, explains trade-offs, and shows how to validate the result clearly.
##### Question
Design and implement APIs to create an account, deposit money into an existing account, and transfer funds between two accounts while maintaining atomic balance updates and proper error handling.
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 Implement account CRUD and transfer states assumptions, handles edge cases, explains trade-offs, and shows how to validate the result clearly.
You are building a small money-movement service for a single currency. The system must support creating accounts, depositing money, and transferring funds between accounts. Operations must be atomic and resilient to concurrency issues, and should provide clear, consistent error handling.
Assume a service with a relational database. You may choose any language/framework; document your choices and trade-offs.
Requirements
APIs
Create account
Deposit into an existing account
Transfer funds between two existing accounts
Correctness and Atomicity
Balance updates must be atomic and consistent under concurrent requests.
Prevent overdrafts; a transfer should fail if the source account lacks funds.
Ensure no partial updates (transfer must either fully succeed or have no effect).
Concurrency Control
Handle concurrent deposits/transfers safely (no lost updates, no race conditions).
Avoid deadlocks.
Idempotency and Error Handling
Make deposit and transfer endpoints idempotent (e.g., via an Idempotency-Key header).
Define clear error codes/messages (validation, not found, insufficient funds, conflicts).
Data Modeling
Use an integer-based amount (e.g., cents) to avoid floating-point errors.
Persist a minimal audit trail (e.g., ledger entries) for deposits/transfers.
Documentation & Tests
Document API contracts (requests/responses), validation rules, and error schema.
Provide a basic test plan covering core and edge cases (including concurrency and idempotency).
Deliverables
Data model (DDL or schema definition).
API specification (routes, payloads, responses, error schema).
Implementation outline with transaction logic ensuring atomicity.
Notes on concurrency control, idempotency, and validation.
Test plan (and tests if you implement code).
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?