Transaction case study: reliable stock and payment updates

≈ 45 min

Transaction case study: reliable stock and payment updates

A reliable transaction case study starts with a statement that must remain true. For stock and payment, a product quantity cannot be negative, a successful order has one recorded payment or a clear pending state, and a failed order does not reserve stock forever. The database transaction protects changes that must agree; the surrounding workflow communicates what the user should see if an external step is delayed.

Payment providers and databases are separate systems. A payment request may succeed remotely while the local server loses its response. Instead of double-charging on retry, store a payment reference and use idempotency: repeating the same request produces the same final result rather than a second charge. Reconciliation checks pending records later against the provider.

Worked reasoning. A checkout starts a local order with PENDING status, sends one idempotent payment request, then in a transaction records the confirmed payment, decrements stock and marks the order PAID. If the response times out, the system does not guess; it checks the payment reference before retrying. The user sees a clear pending message rather than an invented failure.

Exam lens. Separate local atomic changes from external uncertainty. Marks come from explaining what prevents duplicate or partial outcomes, not from saying “use a transaction” alone.

Which statement is the most defensible principle for Transaction case study: reliable stock and payment updates?

Model a transaction from the business invariant outward, including failure, retry and user-facing recovery.

Treat an implementation detail as more important than the stated rule.

Assume one successful run proves the system is correct in every case.

Avoid recording assumptions, limits or failure conditions.

Enter the key term for Transaction case study: reliable stock and payment updates. Which transaction property preserves stated data rules before and after a committed transaction?

A payment request times out after leaving the system. What should the checkout do before sending another charge?

Look up or reconcile the existing idempotency reference so it can determine whether the first request already succeeded.

Use a larger class or broader permission without stating a rule.

Trust the first output and skip a boundary or failure check.

Hide the decision so affected people cannot inspect it.

Name the concise safeguard or principle that completes this lesson’s scenario: A payment request times out after leaving the system. What should the checkout do before sending another charge?