ORIGINAL COMPANY-CONTEXT PRACTICE
Handle a timed-out payment request
Original practice scenario inspired by Citigroup Inc.'s public business context; this is not a reported interview question or a description of its internal systems. A fictional banking API times out after submitting a payment. The client cannot tell whether submission succeeded and retries. Describe the application state machine and tests that prevent an accidental second submission.
Written for independent practice using company context; this is not a verified question from a company interview.
A REASONED APPROACH
Model answer.
Give the business operation a stable idempotency key and a durable state machine. A timeout means the outcome is unknown, rather than proving failure or authorizing a fresh payment.
Work through it
- Atomically reserve the key with a canonical request fingerprint. Reject reuse with materially different payment details instead of returning an unrelated earlier result.
- Move through pending, submitted, confirmed, or failed states using guarded transitions. Reconcile ambiguous submissions with the downstream reference before retrying an irreversible action.
- Test simultaneous duplicate requests, a crash after submission but before acknowledgement, delayed confirmation, and a retry after the original response was lost.
Tradeoffs to discuss
- An extra status lookup adds latency but preserves correctness during ambiguity. Key retention and reconciliation windows must match the operation lifecycle.
Common pitfalls
- A check-then-insert race permits duplicates.
- Catching every timeout and marking the payment failed erases the distinction between failure and uncertainty.