ORIGINAL COMPANY-CONTEXT PRACTICE
Post a transfer exactly once under retry
Original practice scenario: A hypothetical banking service debits one account and credits another. The client times out after submission and retries. Describe the transaction and idempotency design.
Written for independent practice using company context; this is not a verified question from a company interview.
A REASONED APPROACH
Model answer.
Preserve a balanced ledger transaction under a stable request identity. A timeout means the client lacks an outcome, not that the transfer failed or should be posted again.
Work through it
- Validate authorization, currency and amount, then bind an idempotency key to the request payload so conflicting reuse can be rejected.
- Commit debit, credit and durable request outcome atomically within the declared ledger boundary, applying appropriate account-concurrency and balance rules.
- Return the stored outcome for repeated identical requests and provide status lookup; reconcile any separately executed external transfer through explicit pending and compensation states.
Tradeoffs to discuss
- A single transactional ledger simplifies balance invariants but may limit cross-system reach; external participants require a recoverable protocol.
Common pitfalls
- Never treat an identical key with a different amount as a harmless retry.
- Distinguish client response delivery from transaction commitment, and test failures on both sides of that boundary.