ORIGINAL TECHNICAL PRACTICE
Protect a multi-row invariant
Two accounts must be updated together for a transfer-like ledger operation. Which guarantees belong in the transaction?
Written for independent practice. The model answer presents one approach; clarify constraints and explain alternatives.
A REASONED APPROACH
Model answer.
Treat the operation as one atomic change with explicit validation and concurrency behavior. A transaction groups writes, but correct constraints, isolation and retry handling still determine whether the invariant holds.
Work through it
- Validate units, account identities and authorized operation state. Use exact arithmetic and record a stable operation identifier to support idempotency.
- Apply related changes in one transaction and enforce the balance or ledger invariant with the database’s available constraints and locking or conditional-write strategy.
- Test concurrent conflicting operations, failure between statements and retry after an uncertain response. Reconcile the committed operation by its ID before applying it again.
Tradeoffs to discuss
- Stronger isolation can reduce anomalies while increasing contention or serialization retries. An append-only ledger can improve auditability but still needs a correct posting protocol.
Common pitfalls
- Committing each statement separately permits partial changes. Repeating a committed operation because its response was lost can violate the invariant even when each transaction is internally atomic.