That is a good part of the motivation why we created Restate.
We built Apache Flink before and even tried to use it for transactional use cases.

Restate is the transactional event-processing twin to stream processing. With an API that looks like durable functions/execution/state/rpc.

To visualize the state machine across services, you could export OTEL traces and use a tool like Jaeger to get the dependency diagram.

Future versions of the UI will have a timeline view, showing when what step was executed. That is not a state machine, but still helpful.

Is any of that helpful?

To develop with a State Machine, you can use XState with Restate.
See here for details: e.g., using it with XState. Is that
restate.dev/blog/persist...
👇

True, not having an explicit state machine is a pity, but also somewhat a feature: It works with implicit state machines and dynamic control flow, e.g, as a backend for AI Agents.

But there are ways to get state machines: 👇

Thank you so much for the kind words!

It’s really impressive! I almost went down the path of building a stateful functions implementation in Rust but discovered how much scaffolding was required to be useful. Really happy to see you all have put those pieces together with Restate!

It has been quite a journey from Stateful Functions to Restate - and while Restate can do a lot more, the Stateful Functions roots are quite visible, specifically in the Virtual Objects Api.

Thank you so much for the kind words!

Restate is much simpler than Flink, however, grasping what it does isn't straight forward given how differently it works. This tutorial is fantastic and worth the time:

But I would agree that BookKeeper is an underrated piece and a hidden gem of distributed systems design.

One reason why Restate mentions Delos frequently is because our lead runtime architect worked with Delos before and adopted the vocabulary. Plus Restate internally has the heterogeneous loglet chain abstraction.

Totally - I learned a ton from the BookKeeper design and your blog posts and there is a lot of similarity to Delos. We discussed this a lot internally.

That is exactly right - what would be a better term? There is some simplification of the coordination happening here, because it centralizes it - like updating the state under a lock.

That's a fair comment - maybe the better way to phrase this is replacing different forms of coordination with multiple independent systems, with one type of coordination, which can be also pretty transparently abstracted in the application, so you keep coordination out of your code.
Would that work?

I guess the headline is brief - I would phrase it as every system is a log and and interpreter of events stored in the log (in the broadest sense).

Maybe the biggest one is the per-key granularity in Restate, and what is conceptually conditional appends (only append if no newer retry subsumed event handler).

This can be built on top of the log (in Restate its above the physical log partition layer), but more efficient if tightly integrated.

I have this slide from a presentation at Kafka Summit / Current about that.