DBOS and how durable execution shortens temporal complexity

#dbos #temporal #durableexecution #workflows

Some backend problems look simple in a diagram and miserable in production.

A customer starts a process. Maybe it is subscription activation. Maybe it is onboarding. Maybe it is a money movement. The system validates something, writes a row, calls a provider, emits an event, updates a ledger, sends a notification, and schedules a follow-up.

Then the process dies after step three. Not before step three. After it.

That detail is where the pain lives. Something real happened. Money moved. A provider accepted a request. A customer entitlement changed. An event went out and another service reacted to it. Restarting from the top is wrong. Pretending nothing happened is worse. Doing the next step twice might be illegal or expensive.

For years, serious fintech teams rebuilt this themselves. At a fintech in the Americas, the answer was the usual toolbox: sagas, Kafka, idempotency keys, reconciliation jobs, dashboards, and retry discipline. At a bank I work with now in the Gulf, I recently met the same problem through DBOS, where workflows and scheduled sweeps are checkpointed so a crashed process can resume instead of starting over.

This is not a DBOS review. I have not used it long enough to write that honestly.

The interesting part is bigger than DBOS. Durable execution is moving from "platform mechanism each team builds" to "property you can install." The old question was, "How do we build a workflow engine that survives crashes?" The newer question is, "Where should it live?"

That is a better question, but it is not an easier one.

the saga tax

Sagas were the correct response to a world where one operation crossed services and no single database transaction could cover it.

The pattern is straightforward: split the operation into steps. Each step commits local work. If a later step fails, compensate where reversal makes sense. Make external calls idempotent. Persist enough state to know what happened. Add retries, timeouts, and reconciliation because retries and compensation never cover every edge case.

That last sentence is where architecture diagrams usually lie by omission.

The mechanism is only half the system. The rest is ownership. Someone needs to define the state machine. Someone needs to decide whether a failed provider call is retryable. Someone needs to decide whether an already-created account should be disabled, refunded, ignored, or pushed into manual review.

But building it well is expensive. You end up maintaining idempotency libraries, saga conventions, event schemas, retry policies, dead-letter queues, reconciliation jobs, repair tools, and replay rules.

Most teams were not trying to innovate on crash recovery. They were trying to ship business flows. The durability layer was necessary plumbing, not product differentiation.

That is usually the moment a category is ready to become a product.

what DBOS and Temporal change

DBOS and Temporal come from different angles, but they attack the same failure: a workflow should remember what already completed.

Temporal is the more established reference point. You run workers with your workflow and activity code. The Temporal service stores workflow state, event history, task queues, and schedules. Temporal Cloud positions itself as the managed durable execution control plane: your workers stay in your environment, while Temporal stores encrypted workflow state and orchestrates execution. Its cloud pricing reflects that: plans plus usage, with Actions as the main consumption unit and storage metered separately.

DBOS feels different because it sits closer to the application. The current docs describe it as a library for reliable programs, with durable workflows, queues, and scheduled jobs. DBOS Transact is open source and backed by a system database, with Postgres or CockroachDB for production, and SQLite in some SDKs for local development. DBOS Conductor is the paid management layer: monitoring, tracing, recovery, replay, forking, and support. The public pricing I found is checkpoint-based, with Pro at $99/month and Teams at $499/month at the time I checked.

That product difference matters.

Temporal says, in effect, "Run your business logic in workers, and let our service be the durable orchestration layer."

DBOS says, in effect, "Keep writing application code, annotate the durable parts, and store the workflow checkpoints in a database you own."

Both are trying to make the crash boundary boring. If step one completed, do not run it again because the process restarted. If a workflow sleeps until tomorrow, it should still wake up tomorrow after a deploy or crash. If a scheduled sweep fires once per interval, the system should know it already ran.

That is not magic. It is persisted execution state.

The magic is that you no longer have to build the persistence mechanism yourself.

what is still yours

This is where teams get in trouble. They hear "exactly once" or "automatic recovery" and assume the hard part moved into the tool.

It did not.

The tool can remember that a step finished. It cannot tell you whether the step was right.

If step three calls a payment provider, the durable workflow can avoid calling it again after a crash if the step result was checkpointed. Great. But what if the process crashed after the provider accepted the request and before your code recorded the result? What if the provider timed out but later completed the operation?

Those are not framework questions. Those are domain questions.

Durable execution makes boundaries visible. That is the value. It forces you to ask what a step is, what can be retried, what must be idempotent, and what needs compensation.

The step boundary is the design.

A bad workflow in DBOS or Temporal is still a bad workflow. You can checkpoint nonsense. You can retry a non-idempotent side effect.

That sounds harsh, but it is useful. Durable execution reduces the custom plumbing required to make workflows survive. It does not reduce the thinking required to make workflows correct.

I still want the same questions answered before trusting any multi-step flow:

What is the business invariant after each step?
Which external calls accept idempotency keys, and what are their retention windows?
Which failures are retryable, which require compensation, and which require manual review?
What state can support reconcile jobs independently of the workflow engine?
Who owns stuck workflow repair when the tool resumes correctly but the business state is still weird?

durability as a purchasable property

This fits a wider pattern: boring control-plane properties become products.

A decade ago, many teams built their own deployment orchestration, secrets distribution, service discovery, leader election, job queues, feature flags, audit trails, and identity glue. Some of that still happens, but far less of it needs to start from scratch. The mechanism moved into Kubernetes, managed cloud services, hosted CI, identity platforms, and internal developer platforms.

Durable execution is joining that list.

That does not mean every team should adopt DBOS or Temporal. A cron job plus a status table is still fine for many workflows. A queue and an idempotent worker are enough for plenty of jobs. If the business process is short, local, and easy to replay, do not import a workflow platform just to feel serious.

But once a process crosses time, services, money, or customer-visible state, the old hand-rolled approach deserves pressure. Not because sagas are obsolete, but because generic saga infrastructure is no longer as defensible to build by default.

The work shifts. Less time building the crash-resume mechanism. More time deciding where the durable boundary belongs. Less time inventing another retry framework. More time naming the compensation semantics honestly.

That is a good trade.

The future here is not that durable execution removes complexity. The future is that it makes one layer of complexity boring enough to buy, install, or standardize. Then engineers can spend more attention on the real system: the business meaning of each step.

That is the part no framework can own for you.