Real World Akka.NET Clustering: Process Managers and Long-Running Operations

Using Process Managers with Akka.Persistence and Akka.Cluster.Sharding to Manage Complex, Long-Running Workflows

In our previous installment of “Real World Akka.NET Clustering”, we covered state machines - the tried and true tool for modeling event-driven behavior for business entities inside your domain. And we also demonstrated that using Akka.NET programming techniques such as behavior-switching it’s straightforward to implement them with actors.

In this post we’re going to take our discussion of real-world Akka.NET actors to a higher level and discuss how to use the process manager pattern with actors to model long-running, stateful workflows that naturally occur in all sorts of business domains.

Process Managers

What is a process manager? A process manager is a state machine used to direct a dynamic, stateful workflow. In the context of modern software applications most process managers tend to be responsible for managing distributed workflows that are executed across different services or multiple instances of a service.

Process managers are:

  1. Reentrant - when we say “long-running” in the context of a workflow this often means durations measured in minutes, hours, or days - not seconds. Therefore, process managers are often programmed so they can be passivated (i.e. put to sleep) and recovered at a future point in time. We typically accomplish this using Akka.Cluster.Sharding in Akka.NET.
  2. Durable - in order to be reentrant process managers must persist their state to a durable store of some kind, typically either a cloud filesystem or a database. This is a good fit for Akka.Persistence.
  3. Driven by State Changes - process managers determine the next course of action in a workflow based on the output of the current and previous states. If we’re in error, perhaps we retry the most recent failed operation. If the operation failed irrecoverably, maybe we need to perform some reverisions and send a report back upstream.
  4. Not Responsible for...

Phobos v1.0.0 - Programmatic Configuration, Improved Integrations, and Reduced Pricing

Phobos 1.0.0 is Cheaper, Faster, and Better Than Before

Phobos logo

Phobos is Petabridge’s application performance monitoring (APM) integration library for Akka.NET, which we released originally back in 2018. Since then it’s undergone some major changes and transformations in order to better support Akka.NET and Akka.NET users.

Short Version

  • Phobos, our Akka.NET application performance monitoring (APM) library that automatically traces and measures actor activity without requiring you to write any instrumentation code, 1.0.0 is now available.
  • It now easily integrates with non-Akka.NET technologies such as ASP.NET and works with a much larger selection of tracing and metrics APM systems than it did before.
  • Phobos now only costs $4,000 per year per organization with no limitations on the number of seats or nodes it’s installed upon.
  • You can buy Phobos instantly online via credit card at Sdkbin.
  • We offer a full 30-day money back guarantee, so if you contact us within 30 days of your purchase and are dissatisfied with your purchase we will refund you in full.
  • Each Phobos subscription comes with support provided by the Petabridge team, so if you need help installing / configuring / deploying Phobos or if it’s not capturing the data you need you can ask us to help at no additional charge.

You can learn more about Phobos at or buy instantly online at

What Phobos Does

Phobos is a set of properietary NuGet packages that you can install into a pre-existing Akka.NET application and automatically begin capturing operational metrics and tracing data, collectively called “telemetry” data, without needing write any APM decorator code.

Real World Akka.NET Clustering: State Machines

Using Akka.Cluster and State Machines to Build Reactive Systems

Petabridge recently launched its first cloud service, Sdkbin, and it’s been a great opportunity for our team to use the Akka.NET tools, patterns, and practices that we’ve been recommending to our customers for years.

In this blog post I’m going to walk through one of the most universal real-world Akka.NET actor patterns: the state machine.

Finite State Machines: a Primer

One of the major drawbacks of web programming is that due to its stateless and non-local affinity, many programming patterns that were commonplace in embedded, desktop, and client programming have lost their importance in everyday programming. These “lost patterns” tend to be stateful ones - and none more so than the “finite state machine” or “FSM” for shorthand.

Finite State Machine concept

The idea behind a finite state machine is simple but powerful:

  1. For a given type of entity modeled in your software system it can exist in one of many possible states - but it can only occupy a single state at a time;
  2. An entity usually has some “state data” objects that provide contextual information for the current unit of work in process - i.e. an Order entity might be in an Open state and have an OrderData object that contains a unique orderId, customerId, and so on;
  3. As the state machine processes events both its state and its state data can change - in particular, the state machine can transition from one state to another in response to 1 or more events being processed; and
  4. States can be re-entrant - an entity can return to its original state in the event of a timeout, error, or based on the type of event it processed.

When Do You Need a State Machine?