The double charge
A flaky connection retries a payment at 2 a.m. Your customer wakes up billed twice, and you spend the morning on refunds and apology emails. Cleaning up duplicates after the fact is guesswork.
Slaap rustigData foundation
Veilig opslaan
De server checkt elke schrijfactie. Foute invoer en data van het verkeerde bedrijf komen er niet in.
De server checkt elke schrijfactie. Foute invoer en data van het verkeerde bedrijf komen er niet in.
1
place that writes to your database
1
step that saves data, jobs, and receipt together
3
kinds of retry keys supported
2 van 6 in Slaap rustig
Het probleem dat dit oplost
Zonder een gedeelde basis bouwt elk team deze randgevallen opnieuw — en anders.
The job that ran for nothing
The save failed, but the follow-up email still went out. Or the save worked and the job silently vanished. When data and side effects live in separate systems, they drift the moment anything errors.
The screen that lies
The UI says saved. A refresh says otherwise. Two people edit the same row and one edit quietly disappears. Nobody finds out until a customer does.
Hoe het werkt
Het mechanisme van begin tot eind, zoals het in de repository is geïmplementeerd.
- 1
Bad input bounces at the door
Every write is checked against a shared contract before it touches your data. The same check runs on the first try and on every retry.
- 2
Duplicates wait in line
A database lock makes two identical requests queue up instead of racing. Then the server checks if this save already has a receipt.
- 3
Everything commits together
The data change, its background jobs, and the receipt save in one database transaction. All of it lands, or none of it does.
- 4
Retries replay the receipt
A repeat request finds the receipt and gets the original answer back. Reusing an ID for a different write gets rejected.
Interactief voorbeeld
Bekijk het in werking
Deze rondleiding toont het geïmplementeerde backendcontract zonder account, credentials of providercalls.
Interactief voorbeeld
Follow the implemented lifecycle
- Parse inputHuidig
- Derive identityWachtend
- Authorize scopeWachtend
- Commit onceWachtend
Stap 1 van 4: Parse input
Alleen deterministische voorbeelddata. De interactie gebruikt geen account-, provider- of netwerkverbinding.
Kernpunten
Waarom dit belangrijk is
One door for writes
Every change goes through the server. The browser can read, but it can never write straight to your database.
Retries get the same answer
Each save keeps a receipt. Send the same request again and you get the original result back, not a second row.
Follow-up work can't get lost
Background jobs save in the same step as the data. If the save rolls back, the job never runs.
Technische garanties
Wat dit wel en niet belooft
Veiligheidsgrens
Achter de schermen houden autorisatie, tenantgrenzen en foutafhandeling één duidelijke eigenaar. Zo blijft de snelle ervaring voor gebruikers gekoppeld aan veilig herstel als het misgaat.
Implementatiebewijs
De grens hierboven is geen claim maar code. Deze bestanden dragen het contract:
src/server/transactions.tssrc/server/permissions.tsdocs/CONVENTIONS.md
Vragen
Veelgestelde vragen
Verwante functies
Deze functies delen contracten en grenzen met deze pagina.
Bouw verder op Veilig opslaan
De documentatie beschrijft dezelfde contracten die deze pagina demonstreert.