←back to thread

Show HN: DBOS Java – Postgres-Backed Durable Workflows

(github.com)
114 points KraftyOne | 2 comments | 13 Nov 25 20:33 UTC | HN request time: 0s | source

Hi HN - I’m Peter, here with Harry (devhawk), and we’re building DBOS Java, an open-source Java library for durable workflows, backed by Postgres.

https://github.com/dbos-inc/dbos-transact-java

Essentially, DBOS helps you write long-lived, reliable code that can survive failures, restarts, and crashes without losing state or duplicating work. As your workflows run, it checkpoints each step they take in a Postgres database. When a process stops (fails, restarts, or crashes), your program can recover from those checkpoints to restore its exact state and continue from where it left off, as if nothing happened.

In practice, this makes it easier to build reliable systems for use cases like AI agents, payments, data synchronization, or anything that takes hours, days, or weeks to complete. Rather than bolting on ad-hoc retry logic and database checkpoints, durable workflows give you one consistent model for ensuring your programs can recover from any failure from exactly where they left off.

This library contains all you need to add durable workflows to your program: there's no separate service or orchestrator or any external dependencies except Postgres. Because it's just a library, you can incrementally add it to your projects, and it works out of the box with frameworks like Spring. And because it's built on Postgres, it natively supports all the tooling you're familiar with (backups, GUIs, CLI tools) and works with any Postgres provider.

If you want to try it out, check out the quickstart:

https://docs.dbos.dev/quickstart?language=java

We'd love to hear what you think! We’ll be in the comments for the rest of the day to answer any questions.

Show context
rileymichael ◴[13 Nov 25 22:58 UTC] No.45921834[source]▶
glad to see the java sdk released, i've been following it for a while.

one of the rough edges i've noticed w/DBOS is for workflows that span multiple services. all of the examples are contained in a single application and thus use a single dbos 'system db' instance. if you have multiple services (as you often do in the real world) that need to participate in a workflow.. you really can't. you need to break them into multiple workflows and enqueue them in each service by creating an instance of the dbos client pointed at the other services system db. aside from the obvious overhead from fragmenting a workflow into multiple (and that you have to push to the service instead of a worker pulling the step), that means that every service needs to be aware of and have access to, every other services system db. also worth noting that sharing a single system db between services was not advised when i asked.

(docs for the above: https://docs.dbos.dev/architecture#using-dbos-in-a-distribut...)

replies(2): >>45921970 #>>45922049 #
1. jedberg ◴[13 Nov 25 23:23 UTC] No.45922049[source]▶
The pattern I would recommend in such cases is having one service be responsible for the overall workflow and then call the other services as steps.

So if you were for example running a website and wanted to have a "cancellation" flow, you'd have the cancellation service with the workflow inside of it, which would have all the steps defined, like

1) disable user account

2) mark user data as archived

3) cancel recurring payments

And then each step would call the service that actually does that work, using an idempotency key. Each service might have its own internal workflows to accomplish each task. In this case step 1 would call the accounts service, step two would call the storage service, and step three would call the payment service.

But then you have a clean reusable interface in each service, as well as a single service responsible for the workflow.

replies(1): >>45922272 #
2. rileymichael ◴[13 Nov 25 23:56 UTC] No.45922272[source]▶
the OP wasn't clear but that's effectively what i settled on by launching workflows (within steps) via the dbos client. keeping that an implementation detail in each service though is probably better + solves the db awareness, just need to do the endpoint/rpc plumbing. thanks!