Home / Product / Transactions and failure control

Keep multi-step work coherent

Commit every required record change together inside one transaction.

Commit required record changes together and declare which optional outcomes may continue after a recoverable condition.

See what it changes Technical guide ↗

Define transaction boundaries and outcome rules for product actions.

Begin one product operationApprove, publish, import, or fulfill

Complete its related record changesSeveral steps share one boundary

Commit a coherent resultOr roll the database work back

Commit required record changes together inside one database transaction.

01Protect related changesCommit all required record changes together inside one database transaction.

02Declare every action outcome as required or optional and assign its continuation rule.Mark the step optional, record its outcome, and continue according to the declared action rule.

03Give callers one resultReturn success only after the core work reaches its boundary.

Why it matters

Commit all required record changes together or roll the transaction back.

Create the invitation membership and shipment record inside the same transaction as their parent operation. Multi-step work becomes dangerous when every change commits independently.

Daptin runs action-related database work inside a transaction. Commit protected record changes after every required outcome completes successfully. Allow a declared optional outcome to continue while recording its result for operators.

Protect database changes with a transaction and persist outside work for idempotent delivery and recovery. Provider calls, mail delivery, and other external effects still need retry and recovery design.

Keep core data coherent

Treat related database changes as one product decision.

Separate required from optional work

Declare a nonessential follow-up optional and record its outcome beside the action.

Show each outcome’s required or optional status, continuation rule, and recorded result.

Return a clear action result and record the recovery path for every incomplete optional outcome.

How it fits

Part of one connected backend.

Apply transaction rules to the same records, users, permissions, and actions that power the application.

Step 1Open

The action begins a database transaction.

Step 2Work

Related record outcomes run in order.

Step 3Decide

Use each outcome’s declared rule to commit the transaction or continue the action.

Step 4Finish

Commit protected database changes after every required outcome completes; otherwise roll them back.

What it enables

Use it in products people recognize.

Start from the experience you want to create; the backend capability supports the work behind it.

Membership change

Create the membership and update the invitation together.

Order transition

Record the status, owner, and related fulfilment data coherently.

Bulk correction

Apply related record updates inside one transaction and commit them as a complete set.

Connected by design

Mark each action outcome as required or optional and apply its declared continuation rule.

Use shared records, identities, permissions, and actions to define each transaction boundary and outcome rule.

Know the boundary

What Daptin leaves in your hands.

Persist email and provider work before dispatch, then use idempotency keys and recorded outcomes for recovery. Design external effects around durable records, idempotency where available, retries, and honest status.

Understand the operating responsibility →

Build from one foundation

Apply transaction boundaries and outcome rules inside the same actions that update product records.

Run Daptin locally, explore the live administration surface, and follow one complete application path.

Get Daptin Explore all capabilities