A Full Stack engineer who makes AI act safely

Problem

An external Meta call and a database write cannot share a transaction, so a failure and retry could execute the same request twice.

Solution

• Claimed an idempotency key before execution so a duplicate request could not enter.
• Released the claim when execution failed, making retries safe.
• When the Meta call succeeded but follow-up processing failed, recorded the result and blocked any further execution.

Problem

The plan a user approved could differ from the plan present at execution time, which is an integrity risk.

Solution

• Pinned the plan with a proposal_hash and verified that the approved content had not changed.
• Re-checked approval state, policy, permissions, and expiry immediately before execution.
• Normalized budgets to integer KRW so amounts could not be interpreted two ways.

Problem

When an approval request times out, there is no way to know whether the money moved. Treating it as 'not charged' when it was charged leaves money billed with no identifier to cancel against.

Solution

• Treated only a definite rejection (4xx) as not charged; timeouts and 5xx are all treated as charged.
• Recorded the approval identifier carried on the exception so the cancellation target is never lost.
• Absorbed the 'already cancelled' response as success, since that is what a cancellation returns when nothing was charged.

Problem

Refund follow-up has five steps: external cancellation, credit restore, coupon restore, settlement exclusion, order finalisation. As one transaction, a late failure rolls back earlier successes; stopping at the first failure skips settlement exclusion, and a refunded order still pays out to the instructor.

Solution

• Ran each step in its own transaction and recorded success and failure as rows.
• Swallowed the exception on a failed step so the remaining steps still ran.
• Let a five-minute batch resume failed steps, up to five attempts.