We build what is effectively a durable execution "engine" for our orchestrator (ours is backed by boltdb and not SQLite, which I objected to, correctly). The steps in our workflows build running virtual machines and include things like allocating addresses, loading BPF programs, preparing root filesystems, and registering services.

Short answer: we need to be able to redeploy and bounce the orchestrator without worrying about what stage each running VM on our platform is in.

JP, the dev that built this out for us, talks a bit about the design rationale (search for "Cadence") here:

https://fly.io/blog/the-exit-interview-jp/

The library itself is open:

https://github.com/superfly/fsm