Make repeated settlement uploads converge on one batch
An upload times out after committing. Finance retries the same file and sees every payout twice. Two browser tabs can also submit it together.
- Focused work estimate
- 2h 30m + prerequisites
- Priority in the scenario
- High
- Engineering practice
- Idempotency · Transactions · Concurrency
Estimated field mix
- Backend60%
- Database engineering40%
Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence.
Review it, then add it to your workspace.
The board opens an editable draft; nothing is saved until you confirm it. Sign-in and workspace permissions apply, and Demo boards remain ephemeral.
Project context
A fictional subscription service invoices in USD and EUR. Finance currently compares a payment-provider CSV with database exports; late refunds and retried imports make the monthly close unreliable. Work on synthetic ledger entries only.
Setup prerequisites
- REST APIs
- SQL transactions
- Integer money representation
Preceding work
Complete these dependencies, or supply their agreed outputs before taking this ticket.
Acceptance criteria
- Identical bytes within one merchant resolve to the same batch identity.
- Concurrent submissions create one committed batch and one set of rows.
- A different file with a reused client request key returns a conflict.
Implementation constraints
- Scope deduplication to the merchant and retain the original content hash.
Verification to include
- Submit the same file concurrently and compare persisted counts.
- Reuse a request key with a changed amount and assert conflict.
Deliverables
- Idempotent import command and concurrency reproduction
Rollout and recovery
Enable for one synthetic merchant; rollback routing while preserving committed batch identities.
Value of the work
For the engineer: Practice monetary invariants, concurrent writes, reconciliation, and operational recovery across one service boundary.
For the team: Review how an engineer makes discrepancies explainable and recoverable before a financial workflow is trusted.
Evidence boundaries
Outcome Evidence: Tests, patches, and runbooks are requested deliverables. They become Outcome Evidence only through a qualified Mission and immutable Evidence IDs.
Ownership Evidence: Independent adaptation must be observed under a declared verification policy and cite immutable Evidence IDs. Completing a planning ticket establishes no Ownership Evidence.