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.
Read 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.
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 synthetic banking dashboard reads balances from regional replicas. Its primary region becomes unavailable while some replicas lag. Design the read behavior without presenting stale balances as current authorization to transfer funds.
Read model answer +
Separate an informational balance display from the authoritative decision to move money. Replica failover can improve display availability while requiring clear freshness and stricter handling of transactional actions.
Work through it
Attach an as-of watermark or version to displayed balances. Define a maximum permitted lag and show unavailable or stale status when that bound cannot be established.
Route transfer authorization through a consistent authoritative path with concurrency control. Do not infer spendable funds solely from a cached display.
Exercise failover with delayed replication, recovery, and repeated client requests. Measure freshness violations alongside availability and latency.
Tradeoffs to discuss
Stronger read consistency can reduce availability during partitions. The appropriate choice can differ between a history screen and a transaction authorization path.
Common pitfalls
A healthy replica endpoint may contain old data.
Replacing unavailable with zero is misleading and can trigger incorrect user decisions.
