Design and Implement Money Movement APIs
Context
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).