A customer signs up for a financial product. The system verifies eligibility, creates an account, charges or reserves money, activates a subscription, emits events, and schedules follow-up checks. Somewhere after step three, the process dies.
Not fails nicely. Dies.
The container is killed. The deploy rolls over. The worker loses its connection. The process restarts after already changing the outside world.
Now the question is not "how do we run this code?"
The question is:
Did we already move money?
That is where the nice little flowchart becomes a production system. If step three charged a card, booked a ledger entry, reserved balance, or called a partner, retrying the whole job from the beginning is not recovery.
we used to build this ourselves
In a fintech on the American continent, the answer was mostly sagas, Kafka, idempotency keys, reconciliation jobs, and discipline.
That architecture is publicly familiar by now. You model a business process as local transactions. Each service owns its data. Events move the process forward. If something goes wrong, another step compensates, retries, or raises the case for later repair. You make peace with eventual consistency, then you pay the operational bill.
And the bill is real.
Every boundary needs idempotency. Every consumer needs to know whether a duplicated message is harmless. Every saga needs a place to record progress. Every timeout needs semantics. Every compensation needs to understand whether reversing is possible or whether the only honest option is manual review.
The mechanism is not glamorous. You end up with workflow state tables, dedupe constraints, Kafka topics, dead-letter queues, dashboards, replay scripts, and reconciliation jobs that ask the most important question in financial software:
"What should be true, and what is actually true?"
That model works. I respect it. It forces engineers to understand the business process properly. It also creates a quiet platform inside the company. At some point, "we just use events" becomes "we own a distributed workflow engine made of conventions."
That is fine when the company is large enough. It is less fine when every team rediscovers the same failure modes because the primitive never became a product inside the engineering platform.
the same problem shows up everywhere
A bank I work with now in the Gulf has similar shapes in different clothes: subscription activation, scheduled sweeps, periodic checks, partner calls, delayed actions, retries after outages. The names change, but the question stays boring and brutal:
Can this multi-step job survive a crash without lying about what already happened?
That is why DBOS caught my attention. Not because I think every team should use DBOS. This is not a DBOS review. The interesting part is more general.
Durable execution has moved from "every serious backend team eventually builds this" to "you can install something that gives you the control-plane property."
That is a big shift.
what DBOS and Temporal actually give you
DBOS and Temporal approach the problem differently, but they sell a similar promise at the developer level: write the workflow in normal code, mark the meaningful steps, and the runtime records enough state to resume after failure.
DBOS Transact is the lighter-weight Postgres-shaped version of that idea. The current DBOS positioning is still that Transact is open source, runs with your application, and stores workflow or queue state in a Postgres-compatible database. DBOS says that database can be your application database. When the app restarts, unfinished workflows continue from the last completed step.
That matters because the adoption path is small. There is no separate workflow cluster required just to start. Postgres is already where many teams keep durable truth. Its paid model is around Pro and Teams tooling, support, Conductor workflow management, checkpoint allowances, and managed or self-hosted options.
Temporal is a bigger platform. A Temporal Workflow records an event history in the Temporal service. Activities get scheduled, started, completed, failed, timed out, or cancelled, and those facts are appended to durable history. When a worker crashes, workflow state can be reconstructed through replay. Temporal Cloud pricing is monthly plans plus consumption based on Actions and Storage.
There is a nice difference in taste here. DBOS says, roughly, "you already have Postgres, let us make execution durable there."
Temporal says, roughly, "run your business process on a dedicated durable execution platform." Both are reasonable. The better choice depends on orchestration weight, operational appetite, workflow lifetime, and whether Postgres as control plane feels like simplicity or coupling.
But the strategic shift is the same in both cases. The question changes from "how do we build crash-safe workflow infrastructure?" to "where should durable execution live, and who owns the semantics when it resumes?"
durability does not decide correctness
Here is the trap.
People hear "durable execution" and mentally translate it to "the hard part is solved."
It is not.
The annoying part got smaller. The hard part became more visible. A framework can record that step three completed. It can avoid running step three again. It can retry step four. It can expose history, logs, status, and maybe let you replay or fork a workflow.
It cannot tell you whether step three was the right boundary.
It cannot tell you whether a failed partner call should be retried for two minutes, two days, or never. It cannot tell you whether a charge should be reversed, whether a ledger posting needs a compensating entry, whether a customer should see "pending" or "failed", or whether a human needs to inspect the case.
Those are domain decisions. In fintech, they are accounting decisions.
This is why I like durable execution as a concept but dislike the magical marketing around it. Failures do not disappear. They become explicit enough to design around.
You still need idempotency at the boundary. If your workflow calls a payment provider, a ledger, a notification service, or a partner API, that boundary must tolerate duplicate requests and ambiguous outcomes. The outside world still needs keys, references, correlation IDs, unique constraints, and reconciliation.
You still need compensation semantics. "Undo" is rarely undo. Financial systems do not delete the past. They post corrections. They reverse, refund, expire, release, cancel, or mark for review. Those words are not synonyms.
You still need to decide what a step is. Too small, and history becomes noisy and expensive. Too large, and a crash forces you to reason about hidden partial progress inside a supposedly atomic step. The useful boundary is usually where the business fact changes.
This is the actual engineering work. Durable execution does not remove it. It makes it harder to hide.
the productization of boring guarantees
A property starts as hard-won internal engineering discipline. Then it becomes a framework feature. Then it becomes a platform primitive. Eventually teams stop asking whether they can build it and start asking how much ownership they still want.
We saw this with observability, secrets management, CI/CD, feature flags, policy engines, identity, rollout controls, and infrastructure drift detection. Durable execution is going through the same treatment.
The boring control-plane property, "this job knows what already happened after a crash", is becoming purchasable.
That is good. I do not want every product team to build a mini Temporal from Kafka and cron. I also do not want every startup to operate a workflow platform because one activation flow has five steps.
The useful future is mixed. Some workflows belong inside application code with a Postgres-backed durable library. Some belong in a dedicated orchestration platform. Some belong as simple database state machines. Some should stay as scheduled reconciliation jobs because the real business process is not synchronous enough to pretend otherwise.
The mature move is naming the failure owner.
If a workflow crashes after money moved, who decides whether to retry, reverse, wait, or escalate? If a scheduled sweep resumes after three hours of downtime, does it process missed windows, skip them, or collapse them? If a partner returns an ambiguous timeout, do you trust local state, their eventual callback, or a reconciliation pull?
DBOS and Temporal can help you preserve progress. They cannot decide what progress means. That is still your job. It was always your job.
That is the part worth paying attention to.
References
- DBOS, durable execution by default
- DBOS pricing
- Temporal Event History documentation
- Temporal Cloud pricing
To test my projects, I use Railway. If you want $20 USD to get started, use this link.
Top comments (0)