Daptin

Home / Product / Transactions and failure control

Keep multi-step work coherent

Make related changes succeed together—or leave the data unchanged.

Keep multi-step record work inside a clear success boundary, while choosing which optional outcomes may continue after a recoverable failure.

See what it changesTechnical guide ↗
01Protect related changesAvoid saving half of a multi-record operation.
02Make failure behavior explicitChoose when an optional step may fail without hiding it.
03Give callers one resultReturn success only after the core work reaches its boundary.
Why it matters

A product operation should not leave half a story in the database.

Imagine accepting an invitation but failing to create the membership, or marking an order fulfilled without recording its shipment. Multi-step work becomes dangerous when every change commits independently.

Daptin runs action-related database work inside a transaction. If a required outcome fails, the record changes can roll back together. Individual outcomes may explicitly continue after an error when they are truly optional.

This creates a predictable data boundary without pretending that outside networks are transactional. Provider calls, mail delivery, and other external effects still need retry and recovery design.

01

Keep core data coherent

Treat related database changes as one product decision.

02

Separate required from optional work

Let a nonessential follow-up fail only when the action says it may.

03

Make error handling visible

Design the response and recovery path instead of accepting silent partial success.

How it fits

Part of one connected backend.

Transactions and failure control does more when it can reuse the records, people, access rules, and workflows already in your application.

Step 1Open

The action begins a database transaction.

Step 2Work

Related record outcomes run in order.

Step 3Decide

A failure stops or continues according to the declared rule.

Step 4Finish

Commit on success or roll back the protected database work.

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 updates without leaving a partially changed set.

Connected by design

Build the next part without starting over.

These capabilities share the same application context, so each one makes transactions and failure control more useful.

Works better together

Actions

Give the transaction a meaningful product boundary.

Explore Actions →Works better together

State tracking

Only record a new lifecycle state when the transition succeeds.

Explore State tracking →Works better together

Outbound mail

Persist communication work when outside delivery cannot be transactional.

Explore Outbound mail →
Know the boundary

What Daptin leaves in your hands.

A database transaction cannot roll back an email already sent or a provider request already accepted. Design external effects around durable records, idempotency where available, retries, and honest status.

Understand the operating responsibility →

Build from one foundation

Make transactions and failure control part of the product—not another disconnected service.

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

Get DaptinExplore all capabilities