Naively without digging into the code I would look at a “streaming over an open connection” as likely to strictly more brittle.
Naively without digging into the code I would look at a “streaming over an open connection” as likely to strictly more brittle.
While the workflow is actively doing work (like calling other services, accessing state or interacting with external services, for example) the server is connected to the workflow deployment via a low-latency bidirectional streaming connection to receive and acknowledge progress that the workflow makes. That way the workflow can finish as fast as possible.
A nice side effect of this model is that you can co-locate your workflow with expensive resources, such as a sandbox, which should be used by all durable actions that the workflow executes. The reason this works is because Restate can inline durable steps (what would be modeled in Temporal as activities, I believe).
So you have fast persistence of events while a handler can make progress, and suspensions while waiting.
While the durable function does fast work and adds steps, it pushes it through a stream. When a wait point comes, it closes and replays on resumption (typical durable execution style).
That gives you the best of both worlds: same long-running workflows with long sleets and suspensions, but also ability to add steps with few ms overhead only.