Common interview mistakes and how to recover

01Recognize a reasoning mistake, not just a missing box

Two people see the same green seat on a cached concert map. Both try to buy it. The design must decide who owns the seat and what happens to each payment.

Consider this flawed answer: “Put the purchase in a queue and retry after a timeout; the queue processes it exactly once.” Identify what is missing:

• A green map entry can be old. It does not reserve the seat for either buyer.
• A queue stores work for a worker to process later. Accepting that work does not mean the seat was acquired or payment completed.
• A payment may succeed before its response is lost. A timeout does not prove that no money moved.

Start the repair with the seat record:

1. Ask the inventory service to claim the seat only while its saved state is available.
2. Make the database check and claim one indivisible operation, so two buyers cannot both win from the same old value.
3. Return a defined conflict to the loser instead of promising a purchase from the map.

This is a conditional reservation: the saved condition must still hold when the claim is accepted. A familiar cache, queue or database name does not replace this operation.

02Repair the failure timeline

Let the winning buyer’s seat reservation be R12. Let P9 identify this intended payment, so every repeat can refer to the same payment rather than create another.

A queue consumer is the worker receiving the task; the broker is the system delivering it. Follow the dangerous sequence:

1. The worker receives payment task P9.
2. The provider charges successfully.
3. The worker crashes before saving the payment result or acknowledging completion to the broker.
4. The broker delivers P9 again because it did not receive completion.

The next attempt must check saved state and use the provider’s supported retry behavior:

1. Look up the payment record for P9. If a completed result is already saved, return it without starting another charge.
2. If the result is missing or uncertain, retry or query the provider using that same supported payment identifier.
3. Save the known result, or save pending status and the provider reference while it is being resolved.
4. Acknowledge the queued work only after the payment record contains either the final result or a pending result that a recovery worker can find and resolve using P9. A crash must not leave the only recovery instruction in this worker’s memory.

A local “processed” flag alone cannot cover the provider call. Saving it before charging can lose a payment; saving it after charging leaves the crash gap above. Check how the provider deduplicates identifiers, how long it remembers them and how status can be queried. If it offers no suitable guarantee, state the remaining duplicate/uncertainty risk honestly.

The broker may deliver a task again: this is at-least-once delivery. A repeated operation with the same intended effect is idempotent. These are different properties.

03Recover clearly and avoid three other traps

Reservation expiry changes what recovery may do. A delayed payment cannot simply recreate ownership of a seat sold to somebody else:

1. Read the current seat owner and reservation state.
2. Resolve P9 with the provider instead of assuming the timeout means failure.
3. If the provider confirms payment, use an inventory transaction to check that this buyer still owns the unexpired reservation and mark that booking confirmed together. If payment definitively failed, record the failure and release only this buyer’s reservation.
4. If money moved without a valid seat claim, record the product’s compensation, such as a refund. Do not confirm a second owner.

Comparing saved purchase state with the provider’s actual result and completing missing steps is reconciliation. Returning money after an irreversible step cannot be kept is one possible compensation.

Repair other interview mistakes with equally specific work:

• If you used a fleet average, inspect the busiest show and what happens after one machine fails.
• If database isolation is unfamiliar, state the required reservation behavior and verify the supported operation.
• If a private read lacks permission checks, add the check before byte delivery and test revoked access.
• If you propose another service, identify the concrete capacity or responsibility it improves and the new network failure it creates.

After a correction, rerun the original failure:

1. Race two buyers for the seat.
2. Lose a charge response.
3. Redeliver the same payment task.
4. Let the reservation expire while payment is uncertain.
5. Verify one accepted owner and the intended payment or recorded compensation.

A useful explanation identifies the changed record and checked condition. Naming “exactly once” without those steps leaves the flaw in place.