The key to a durable workflow is making each step idempotent. Then you don't have to worry about those things. You just run the failed step again. If it already worked the first time, it's a no-op.

For example, stripe lets you include an idempotency key with your request. If you try to make a charge again with the same key, it ignores you. A DE framework like DBOS will automatically generate the idempotency key for you.

But you're correct, if you can't make the operation idempotent, then you have to handle that yourself.

▲

repeekad 4 hours ago | parent [-]

Temporal plus idempotency keys solves probably the majority of infrastructure normally needed for production systems

▲

cyberpunk 3 hours ago | parent [-]

Except to run temporal at scale on prem you’ll need 50x the infra you had before.

▲

jedberg 3 hours ago | parent [-]

Indeed, one of the main selling points of DBOS. All the functionality of Temporal without any of the infrastructure.

	▲	cyberpunk 3 hours ago \| parent [-]
		Ah I don't know if I would agree with that. Temporal does a lot of stuff; we just don't happen to need most of it and it's really heavyweight on the database side (running low 500 or so workflows/second of their own 'hello world' style echo benchmark translates to 100k database ops/second.. DBOS is tied to Postgres, right? That wouldn't scale anywhere near where we need either. Sadly there aren't many shortcuts in this space and pretending there are seems a bit hip at the moment. In the end, mostly everyone who can afford to solve such problems are gonna end up writing their own systems for this.