Idempotency, compensation, and human approvals

Overview

• Idempotency makes repeating the same logical request avoid repeated effects.
• Compensation is a business action that offsets an earlier action when later steps fail.
• Human approvals are authenticated events permitting specific transitions.

Why this matters

Crashes can occur after a side effect succeeds but before its success is recorded.

An everyday example

A receipt number prevents paying the same invoice twice; a refund offsets a payment but does not erase its history.

A technical example

A unique (tenantId, action, idempotencyKey) prevents duplicate claim creation and reuses the existing receipt.

How it works

1. Record request key and payload hash atomically
2. Execute controlled business mutation
3. Save outcome
4. Reuse on retry
5. Compensate according to policy if later work fails.

Architecture and flow

Request/key → deduplication + transaction → receipt → retry returns receipt; later failure → permitted compensation.

The insurance assistant example

Duplicate browser clicks produce one claim. If notification fails, retry notification without creating the claim again.

When to use it

Every externally retried write and every multi-service process with partial failure.

When to avoid it

Do not reuse a key for changed payloads or assume compensation can undo sending an email or disclosing data.

Interview answer

“I use scoped idempotency keys and durable receipts to prevent duplicate effects, and explicit compensation for recoverable partial business failures.”

Benefits, trade-offs, and production considerations

• A read-then-insert check races; enforce uniqueness transactionally.
• Unknown external outcomes require lookup/reconciliation.
• Approval should bind to the exact payload hash and expire when business facts change.